This is one of the ostensible guiding principles of the Washington Post: "The newspaper’s duty is to its readers and to the public at large, and not to the private interests of its owners."
Independence from ownership isn't really a left/right principle. The Washington Post has their set of guiding principles online - I think from those it's pretty clear why there is discontent.
Sorry, but someone who is averse to joins is not a non-expert in SQL, they are a total novice. The answer is like any other programming language. You simply must learn the language fundamentals in order to use it.
It's not really a problem of there being combinatorially many ways to join table A to table B, but rather that unless the join is fully-specified those ways will mostly produce different results. Your tool would need to sniff out these ambiguous cases and either fail or prompt the user to specify what they mean. In either case the user isn't saved from understanding joins.
Once you have SQL, you have datalog. Once you have datalog, you have SQL. The problem isn't the target, it is getting sufficiently rigorous and structured output from the LLM to target anything.
I think the problem is the quirkiness on the English side, not the SQL side. You could translate datalog to SQL or vice versa, but understanding intention from arbitrary english is much harder. And often query results must be 100% accurate and reliable.
I don't really know much about India but they seem to have more illegal immigration than the US does and per https://www.bbc.com/news/world-asia-india-50670393 seem like they have discussions about amnesty there too. My assumption would be that any regional economic power with long borders will struggle with illegal immigration.
On the OP's resume, they claim to have written the "highest performing in-memory database in the world". It's here: https://github.com/carrierdb. There are no users.
Perhaps it is the highest-performing in-memory DB in the world, but it's a competitive space and the claim is extremely grandiose. If I were hiring my assumption would be it's BS. I would recommend the OP collapse the resume to a single-page PDF and ensure it contains only supportable claims.
You seem to think you're disagreeing with me but afaict you're just demonstrating my point, unless your point is just about how (int, int) will get packed. That's what I meant about the column order of indexes. If you have two ints and a bigint, but you need to index it like (int, bigint, int), then you aren't gaining anything there either.
As your example shows, there is no benefit in index size (e.g for supporting FKs) in going from int to bigint for a single key. You end up with the same index size no matter what, not twice the size which was what I took your original post to mean.
Postgres pads tuples to 8 bytes alignment so an indexed single-column int takes the same space as an indexed bigint. That's the usual case for indexed foreign keys.
Differences can appear in multicolumn indexes because two ints takes 8 bytes while two bigints takes 16, however the right layout of columns for an index is not always the layout that minimizes padding.
Reconfiguring tables to use a different kind of unique ID (primary key in this context) can be a much bigger pain than an ordinary column rename if it is in use by foreign key constraints.
If you use a surrogate key, you still need a unique constraint in the table (probably the same columns you would otherwise call your natural PK). If your unique constraint isn't sufficient to capture the difference you mention, you need to add more columns.
However, that's strictly better than the natural PK situation, where you would need to not only add new columns to the key, but also add those columns to all referencing tables.
My guess is orgs that have a real need for a distributed SQL database (which are rare in the space of orgs) will make their choices based on requirements analysis rather than naming.
So probably if you would be turned off enough by the name not to use the software, you don't actually need a distributed SQL database and are not the target customer.
I would distinguish between "local dev environment" and "debugging specific data-dependent customer issue".
My experience is you can usually write the application with no dependencies on customer data, and do local development entirely with synthetic data.
For debugging specific customer escalations or understanding data distributions for your synthetic data modeling, you can use a replica of production. No need to extract just a subset or have devs host it themselves. All access can be controlled and logged this way.
Better than a replica would be something like [1] but that isn't available everywhere.
I agree the problem of "dump a DB sample that respects FK constraints" comes up sometimes and is interesting but I'm not sure I'd use it for the problem you describe.
It would take at least 500-1000 years for the life expectancy to rise to 500-1000 years. Pretending that is very soon, or that people in significant number could even afford that ability after the tech existed (which it won't), seems out of touch.
I think your observation is why you read a lot more about Phillips these days than RFK.
RFK's promoters switched to promoting Phillips when they realized RFK was drawing more conservatives for the antivax stuff, than democrats for the Kennedy name.