So, on a practical note: I'd like it if PostgreSQL supported
alternate languages for queries, as it does for stored procedures.
Yes, I know this will strike some of you as an abomination. I think
we can take that part as read. ;-)
I see two ways of going about this. The quick & dirty way would be to
conditionally hand off the incoming code to a pre-processor, which
would return SQL to be passed along to the rest of the parser. You'd
just add a few lines to parser.c, along the lines of:
#ifdef ALTERNATE_QUERY_LANGUAGE
str = preprocess_the_code(str);
#endif
The rest would be defined outside the existing code. I actually
experimented with this a few years ago, embedding some Chicken Scheme
into PostgreSQL, and it seemed to work reasonably well. Basically, I
looked to see if the incoming query started with "(" and if it didn't,
I just returned the string unaltered. If it did, I parsed as
s-expressions.
The "right", and more flexible way, would be to actually generate your
own parse tree, using the same nodes the native parser does. I'm
sorry to say I didn't stick with that to the point of getting anything
working. One encouraging thing, however is the fact that the parser
is mostly isolated from the rest of the system; if it was highly
integrated, it would be much harder. Although gram.y does hedge a bit
on this:
"In general, nothing in this file should initiate database accesses".
Anyway, one way or the other, I think it could be done.
On Tue, Sep 14, 2021 at 1:32 AM Guyren Howe <guy...@gmail.com> wrote:
>
> A fun philosophical discussion.
>
> I am no fan of “worse is better”, and particularly its poster child, SQL.
>
> The world’s economic output would be substantially higher (5%?) if our
> industry had settled on almost anything other than SQL for relational
> databases.
>
> So much of the design of *almost everything* in our industry is a reaction to
> SQL. ORMs fucking *everywhere* so you don’t have to use SQL. Bad query and
> database design. Inefficient system designs that use ORMs rather than
> relations. NoSQL databases. Countless hours on hours of developer time trying
> to work out how to write something in SQL that would be trivial in, say,
> Datalog.
>
> If I had $5 million to invest in a startup, I would hire as many of the core
> Postgres devs as I could to make a new database with all the sophistication
> of Postgres but based on Datalog (or something similar). (Or maybe add
> Datalog to Postgres). If that could get traction, it would lead in a decade
> to a revolution in productivity in our industry.
--
Ray Brinzer
