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.
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 <tgl@xxxxxxxxxxxxx>, wrote:
Raymond Brinzer <ray.brinzer@xxxxxxxxx> 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
