mattashii

Whilst they may provide a strong signal, I wouldn't call it a guarantee. If I wanted to avoid vibe-coded contributions I might add such files, but with instructions for the agents that they're not allowed to read or touch any of the files in the repository.

I don't think it's that different from pointing out that registering and/or operating a company in e.g. Delaware or Texas is a very different experience from doing so in New York.

If the status column changes, and an index depends on the contents of that status column (be it by referencing it in its columns, or in the index's WHERE filter) then an update of the status column will prevent the HOT optimization from being applied.

Possibly, ballot sheet size?

The national elections in NLD have a single ballot in the whole country, with 10+ parties who each get a column of their candidates on the ballot, and with one box for each of the candidates. In these elections for the 150 seats of parliament, often there are 200+ candidates listed total. As a result, the ballot sheets need to be quite large and so are quite far into the 'unwieldy' part of the handling spectrum.

This size issue also complicates verification and counting, because you have to verify that of all checkboxes, exactly one is filled in, and sorting/counting needs to do this for practically every ballot.

There has been some experimenting with changing the ballot to a 'party' and 'list number' ballot, where you fill in the party of your chosen candidate together with their number on the party list, but AFAIK that has not (yet?) been approved for wider use.

The order returned from the Index Scan is not the ordering requested by the user, so there would still have to be a full (or topk) Sort over the dataset returned from the index scan, which could negate the gains you get from using an Index Scan; PostgreSQL itself does not produce merge join plans that merge a spread of index scans to get suffix-ordered data out of an index.

Epic wasn't fined for putting things on sale. Instead, it was fined for putting pressure on children to buy things that were put on sale; e.g. through wording like "Get it now" and "Grab it", and through design.

For details, check the ruling here (Dutch): https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:RBROT:2...

There is also a lot of money, there is also good management, and there are also lots of incentives.

But management depends on your manager; at scale it becomes likely there are bad apples in every management tree. Incentives may not align with what you want or need, with work From Home policies getting shrunk. Even money sometimes is a point of contention.

That's why they're called generic parameters, not template parameters; the code is generic over all possible parameters, not templated for every possible parameter.

It's true that the transistors are on the order of 50nm, but the conduits for getting the electrons to those transistors are presumably a bit smaller than that.

Probably not 7nm small, but not the full 50 nm either.

Facebook Nederland B.V. is just one of the defendants; the other defendants are Meta Platforms Ireland (based in Ireland), and Meta Platforms Inc. (the main company, based in the USA)

The Dutch subsidiary has been acquitted, as it only managed advertisement income, not the app design.

Meta Platforms Inc. has been acquitted, as it itself doesn't directly provide apps or services in Europe (nor the Netherlands) - legally that's managed by Meta Platforms Ireland and so not Inc.'s responsibility.

Meta Platforms Ireland has been ordered to implement these changes, enforced by the up to 5 million euro fine (see pages 20 and 21 in the verdict)

Judgement (dutch): https://www.bitsoffreedom.nl/wp-content/uploads/2025/10/2025...

The judgement requires Meta to change their platforms within 2 weeks so that the user's choice is persistent. If not implemented in 2 weeks, there is a daily penalty of €100'000, up to a maximum of €5 million.

If stocks are on fire then you should probably value them for their ash contents.

They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade

Minor versions of PostgreSQL have constraints that major versions don't have; in that minor versions in principle don't see new features added. This allows minor versions of the same major release to run against the same data directory without modifications.

However.

Major versions add those new features, at the cost of changes to internals that show up in things like catalog layout. This causes changes in how on-disk data is interpreted, and thus this is incompatible, and unlike minor releases this requires specialized upgrade handling.

Doesn't look like it, no. At least not to the degree that it has updated the table AM interface.

Those are some great features. More than I remembered, and it's only been a year.

Personally, I'm very happy to see parallel builds for GIN indexes get released - (re)index time for those indexes is always a pain. I'm looking forward to further improvements on that front, as there are still some relatively low-hanging fruits that could improve build times even more.

(Opinions are my own, not of my employer)

I think that "under review" claim is doing some very heavy lifting, especially when it relates to their changes to index tuple lifecycle management. The patches that have been submitted are unlikely to get committed in full anytime soon, even after substantial changes to the patches' designs.

PostgreSQL just has not been designed for what OrioleDB is doing, and forcing OrioleDB's designs into PostgreSQL upstream would a lot of (very) sharp edges that the community can't properly test without at least a baseline implementation - which critically hasn't been submitted to upstream. Examples of these sharp edges are varsized TIDs, MVCC-owning indexes, and table AM signalled index inserts.

There are certainly ideas in OrioleDB's designs that PostgreSQL can benefit from (retail index tuple deletion! self-clustering tables!), but these will need careful consideration in how this can be brought into the project without duplicating implementations at nearly every level. A wholesale graft of a downstream fork and then hoping it'll work out well enough is just not how the PostgreSQL project works.

I think what they refer to is that while the interests of the individual and the country almost never align, the government can work to align these interests; e.g. through tariffs on trading with that other country. By doing so, a country can reduce/remove the incentive to trade with that other country's individuals, thus aligning the interests.

Glucose can be used as a component in solid fuels, you just need to find an oxidizer to mix in.

Alternatively, you can break it down into ethanol, which has been used as liquid rocket fuel since at least the first half of the '40s.

I hope that ZeroSSL has improved their policies and procedures in the past years so they're more safe and robust. Four and a half years ago, there were some significant oversights in certificate lifecycle management, TOS, and handling of key material, which needed external parties to notify them of those issues before they fixed them. To me that was an indication of limited awareness of WebPKI and security principles.

See e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1698936, https://bugzilla.mozilla.org/show_bug.cgi?id=1699756

The clearest difference is that in rust these things are explicit rather than implicit. To do this in rust you'd have to use 'static, etc.

You could use 'static, or you can move (partial) ownership of an object into itself with Rc/Arc and locking, causing the underlying counter to never return to 0. It's still very possible to accidentally hold on to a forest.

The percentage of comments in line counts doesn't measure the quality of the comments, nor the quality of the codebase.

It's rather easy to get over 50% by putting a comment above each line of code, containing the output of an LLM that's asked "what does this line do" and supplied with exactly that line of code. It's much harder to make sure the comments make sense and actually add value.

The mass of a star was at some point a nebula, which collapsed into the star.

That collapse reduced the gravitational potential energy of the mass of that nebula, which through accelleration, friction, and pressure, was turned into heat energy.

That heated mass will emit black-body emissions, and so the gravitational energy is now being radiated as light.

Wouldn't it be possible to float teflon balloons (without ever descending to the surface), and use those to carry a launch platform? Samples do not need to be surface samples, the atmosphere itself seems quite interesting already.

And note that you may be able to "fish" for samples from an atmospheric floating platform; there is no specific need to get all the way down to the rocks with your rocket.

Yet emerging markets move incredibly fast, and the goal is to discover those trenches and occupy them.

Well, only if you make it a goal to occupy all the trenches. The EU has realized that it does not want all possible trenches occupied. For example: There is a lot of market share to be had in waste disposal by dumping it in the rivers and oceans. Regulation generally prohibits this, because we don't want our rivers and oceans full of waste.

Capitalist market self-regulation wouldn't have done this without external pressure (regulation, litigation, etc.) because the capitalist market would externalize all costs if it would increase profits.

More powerful than what? If StyroPyro can build handheld 200W+ LED laser device in his workshop [0], why wouldn't a sufficiently funded military be able to build an anti-drone laser with the same (or higher) power output?

Note that his laser burns through various reflective materials, including mirrors, copper, aluminium, and steel.

[0] https://youtu.be/UBVlL0FNbSE

Neon is indeed unrelated to OreoleDB, but Neon does also provide the separation of storage and compute in Postgres which GP asked about ("Postgres needs options for open-source separation of storage and compute"). A mention of Neon (which is Apache 2 licensed) therefore isn't totally unwarranted.

It's more than just one mapping index, though.

The CMU paper indicates the logical keys are either TupleID or Primary Key, while the bridged index is actually a TupleID that resolves to a Primary Key, which resolves to the actual tuple - one more level than indicated by 6.1's explanation of logical pointers.

Kinda. I think it's "just" PostgreSQL behaviour that's to blame here: On replicas, transaction commit visibility order is determined by the order of WAL records; on the primary it's based on when the backend that wrote the transaction notices that its transaction is sufficiently persisted.

See also my comment https://news.ycombinator.com/item?id=43843790 elsewhere in this thread

It's not entirely clear but this isn't an issue in multi instance upstream Postgres clusters?

No, it isn't an issue with single-instance PostgreSQL clusters. Multi-instance PostgreSQL clusters (single primary, plus streaming/physical replicas) are affected.

What they -too- discovered is that PostgreSQL currently doesn't have consistent snapshot behaviour between the primary and replicas. Presumably, read-only transaction T2 was executed on a secondary (replica) node, while T1, T3, and T4 (all modifying transactions) were executed on the primary.

Some background:

Snapshots on secondary PostgreSQL nodes rely on transaction persistence order (location of commit record in WAL) to determine which transactions are visible, while the visibility order on the primary is determined by when the backend that authorized the transaction first got notice that the transaction was completely committed (and then got to marking the transaction as committed). On each of these (primary and secondary) the commit order is consistent across backends that connect to that system, but the commit order may be somewhat different between the primary and the secondary.

There is some work ongoing to improve this, but that's still very much WIP.

The article states a new price of $0.00003 /1k requests, an order of magnitude lower than your indication. Maybe you have miscounted the number of zeroes, or did I miss something in the calculation?