On Fri, Feb 11, 2022 at 12:26 AM Guyren Howe <guy...@gmail.com> wrote:
> I’m not proposing some crackpot half-baked idea here. There are > well-defined and researched alternatives to SQL. > I didn't suggest that you were. Anything which was written, someone had to actually write. > The most fully-developed you-can-use-today offering is Datomic, which uses > Datalog as its query language. If you know Prolog, and how that is kind of > database-like, Datomic is pretty much a variant of Prolog. > > https://www.datomic.com > > I don’t use it because it’s closed source. > And being closed-source, it's not useful here. A concrete spec for what you'd like to see happen at least has potential. A parser that someone has actually written, more so. 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? I've floated a few modest, concrete ideas here, and while the response to them was conservative, I wouldn't call it closed-minded. The message I've gotten from Tom Lane was basically, "here are the problems; show me how this would actually work." I'd have to call that fair; ball's in my court. Being more ambitious, I'd be pleased with a query language which used S-expressions. But I think the road ahead for that would be to say, "Hey, guys, look at this thing I've written. Would you please consider it?" -- Ray Brinzer
