> 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 <guy...@gmail.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 <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 > >
