I get all this. Give me a couple million bucks, and I’ll hire some of the Postgres devs to build a new database. We could crib some of the low-level code from Postgres, but everything above the low level would need to be rewritten.
I was proposing more that we at least provide higher-level, more general, orthogonal etc features in the SQL we have now. eg first-class functions could be added to SQL reasonably easily. On Feb 10, 2022, 22:32 -0800, Tom Lane <t...@sss.pgh.pa.us>, wrote: > Raymond Brinzer <ray.brin...@gmail.com> writes: > > 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? > > Nah, probably not. I mean, not only are we implementing SQL, but > we're implementing it in C. I used better languages than C back > in the seventies ... but here we are. Practical acceptance is > all about infrastructure and compatible tooling, which SQL and C > both have in spades, while academic designs really don't. > > Also, I fear this discussion underestimates the difficulty of > putting some other query language on top of Postgres. I know > you'll say "but the Berkeley guys pasted SQL onto a QUEL engine > back when, so how hard can it be?" In the first place, that > was done on top of maybe ten years worth of work, but now there's > another twenty-five years of development agglomerated on top of > that. So moving things would be more than 3X harder, even if > you make the very-naive assumption that the difficulty is merely > linear. In the second place, QUEL and SQL aren't that far apart > conceptually, and yet we've still had lots of problems that can > be traced to their incompatibilities. Something that was really > different from SQL would be a nightmare to embed into PG. I'll > just point out one example: if you don't like SQL's semantics for > NULL (which no I don't much like either), changing that would > probably require touching tens of thousands of lines of code just > in the PG core, never mind breaking every API used by extensions. > > So for better or worse, Postgres is a SQL engine now. If you > want Datalog or $other_language, you'd be better off starting > or contributing to some other project. > > That's not to say that we can't do stuff around the margins. > The idea of "select all columns except these", for instance, > has been discussed quite a bit, and would probably happen if > we could get consensus on the syntax. But we're not going to > throw away thirty-five years' worth of work to chase some > blue-sky ideas. > > regards, tom lane
