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.
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.
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)
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.
> 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.
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.
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.
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.
> 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.