Re: Can we go beyond the standard to make Postgres radically better?

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us>, wrote:
> Raymond Brinzer <ray(dot)brinzer(at)gmail(dot)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