I’m not proposing some crackpot half-baked idea here. There are well-defined and researched alternatives to SQL.
I didn't suggest that you were. Anything which was written, someone had to actually write.
The most fully-developed you-can-use-today offering is Datomic, which uses Datalog as its query language. If you know Prolog, and how that is kind of database-like, Datomic is pretty much a variant of Prolog.
https://www.datomic.com I don’t use it because it’s closed source.
And being closed-source, it's not useful here. A concrete spec for what you'd like to see happen at least has potential. A parser that someone has actually written, more so.
Will it be accepted here? I don't know; I'm not an insider, or in a position to say. But it'd be a much better pitch than a pep talk, or speaking in generalities about SQL. And that's coming from someone who actually agrees with you. I'm 100% on board with the idea that something better is (badly) needed. But is the idea, here, really to talk a highly successful project into doing a 180 based on this sort of argument? If only the people writing the code saw the light, they'd go read the Datomic site, and start overhauling PostgreSQL?
I've floated a few modest, concrete ideas here, and while the response to them was conservative, I wouldn't call it closed-minded. The message I've gotten from Tom Lane was basically, "here are the problems; show me how this would actually work." I'd have to call that fair; ball's in my court. Being more ambitious, I'd be pleased with a query language which used S-expressions. But I think the road ahead for that would be to say, "Hey, guys, look at this thing I've written. Would you please consider it?"
--