You are trying to draw parallels between the ignition switch in a 1974 Ford Pinto and a 2025 Ford Mustang as if there could be a connection. No.
"The FAA issued Special Airworthiness Information Bulletin (SAIB ) No. NM -18-33 on December 17, 2018, regarding the potential disengagement ofthe fuel control switch locking feature. This SAIB was issued based on reports from operators of Model 737 airplanes that the fuel control switches were installed with the locking feature disengaged. The airworthiness concern was not considered an unsafe condition that would warrant airworthiness directive (AD) by the FAA. The fuel control switch design , including the locking feature, is similar on various Boeing airplane models including part number 4TL837-3D which is fitted in B787-8 aircraft VT-ANB. As per the information from Air India, the suggested inspections were not carried out asthe SAIB was advisory and not mandatory. The scrutiny ofmaintenance records revealed that the throttle control module was replaced on VT-ANB in 2019 and 2023. However, the reason for the replacement was not linked to the fuel control switch. There has been no defect reported pertaining to the fuel control switch since 2023 on VT-ANB."
So while I agree that this being the cause sounds unlikely, referencing the switch issue is something relevant enough for the report itself.
Otherwise, I don't think the issue is spoiling it for audiences as the craft and presentation style count as much or more than the trick itself.
For example, say I was the interviewee and actually said of the SQL question: "Well, to be frank, that question isn't so good for understanding my SQL abilities." I don't think that would be rude or evidence of "being an asshole". A retelling of that story may simply be condensing it down to how that statement was interpreted: as a nice way to say, "that's a stupid question".
We shouldn't get too far into parsing what's in the story as a verbatim telling of what happened. We have the author's impressions of those events and their interpretations of the outcomes to drive home a larger point the author wants to make. That's it.
As you suggest however, tooling for that workload is pretty rare. I want something that focuses on enhancing the database development experience: that understands that there are development workflows for database code which are well controlled and rigorous. So many database tools are focused on being system administrative aids first, or giving you features for directly interacting and <ack> altering the running state of the database and its server from the tool.
The best tool I found for what I do was targeted at Oracle: Allround Automation's PL/SQL Developer (https://www.allroundautomations.com/products/pl-sql-develope...). It's a development oriented tool that, at least last I used it, was focused on serious development work rather than administrative work. Now, I haven't used it in almost 20 years when last I did Oracle development... but I haven't found anything for PostgreSQL that has that thoughtfully implemented database developer centric feature set.
Today I muddle through with DataGrip. DataGrip has just enough of what I need that it's marginally better to work with than just a simple text editor... and also narrowly avoids some misfeatures as not to negate it's utility.
My comments:
The important thing to note that at this point it's just a political posturing and an announcement of intent. They haven't shown any concrete technical plan how this would actually be executed.
> "Of course, we are very pragmatic and realistic, we cannot do this in five years. Planning will continue until the end of the decade, and maybe in 2032 we can start construction."
Once they have the cost estimates and effects on existing rail traffic studied, I bet construction will never start.
"Unification to standard gauge on May 31 – June 1, 1886 [United States]
In 1886, the southern railroads agreed to coordinate changing gauge on all their tracks. After considerable debate and planning, most of the southern rail network was converted from 5 ft (1,524 mm) gauge to 4 ft 9 in (1,448 mm) gauge, then the standard of the Pennsylvania Railroad, over two days beginning on Monday, May 31, 1886. Over a period of 36 hours, tens of thousands of workers pulled the spikes from the west rail of all the broad gauge lines in the South, moved them 3 in (76 mm) east and spiked them back in place.[6] The new gauge was close enough that standard gauge equipment could run on it without problem. By June 1886, all major railroads in North America, an estimated 11,500 miles (18,500 km), were using approximately the same gauge. To facilitate the change, the inside spikes had been hammered into place at the new gauge in advance of the change. Rolling stock was altered to fit the new gauge at shops and rendezvous points throughout the South. The final conversion to true standard gauge took place gradually as part of routine track maintenance.[6] Now, the only broad-gauge rail tracks in the United States are on some city transit systems."
https://en.wikipedia.org/wiki/Track_gauge_in_the_United_Stat...
This statement is just wrong. More accurately, A UUID -can be- a 128 bit number made up of mostly random bits (UUIDv4) which can be represented as a string using a common representation. Sure, that may well be a common case for most, but there are very completely non-random UUID versions as well, such as UUIDv1 or, more recently, the somewhat random UUIDv7.
The author's proposed ID system is less defensible against some of the other UUID versions which aren't addressed. But that initial description suggests that the author doesn't have a complete enough understanding of UUIDs to really make a credible case about UUID problems (which do exist) vs. their own proposed system.