Search Postgresql Archives

Re: The tragedy of SQL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <guyren@xxxxxxxxx> 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






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux