Re: The tragedy of SQL

Поиск
Список
Период
Сортировка
От Raymond Brinzer
Тема Re: The tragedy of SQL
Дата
Msg-id CANasJHnnQXtJ0jHbd2XKcC46pEkioGB3zuQFeLtoxKWGVuQ0BQ@mail.gmail.com
обсуждение исходный текст
Ответ на The tragedy of SQL  (Guyren Howe <guyren@gmail.com>)
Ответы Re: The tragedy of SQL  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-general
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@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
thanSQL 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’thave to use SQL. Bad query and database design. Inefficient system designs that use ORMs rather than relations.
NoSQLdatabases. Countless hours on hours of developer time trying to work out how to write something in SQL that would
betrivial 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
databasewith 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



В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Nolan
Дата:
Сообщение: Re: The tragedy of SQL
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: The tragedy of SQL