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

> 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.

You can check the EdgeDB experiments: https://www.edgedb.com/
*"What is EdgeDB? EdgeDB is a new kind of database that takes the best
parts of relational databases, graph databases, and ORMs. We call it a
graph-relational database."*
*"EdgeDB uses PostgreSQL as its data storage and query execution engine,
benefitting from its exceptional reliability."*
- (2022) https://www.edgedb.com/blog/edgedb-1-0
- (2019) We Can Do Better Than SQL:
https://www.edgedb.com/blog/we-can-do-better-than-sql
"The questions we often hear are “Why create a new query language?” and
“What’s wrong with SQL?”. This post contains answers to both. ... "
- EdgeQL: https://www.edgedb.com/docs/edgeql/index *"EdgeQL is a
spiritual successor to SQL designed with a few core principles in mind."*
- GraphQL: https://www.edgedb.com/docs/graphql/index EdgeDB supports
GraphQL queries natively out of the box.
- Github: https://github.com/edgedb/edgedb

EdgeQL example from the blog;

select
Movie {
title,
rating := math::mean(.ratings.score)
actors: {
name
} order by @credits_order
limit 5,
}
filter
"Zendaya" in .actors.name

Regards,
Imre

Guyren Howe <guyren(at)gmail(dot)com> ezt írta (időpont: 2022. febr. 11., P, 7:43):

> 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
>
>