From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Craig Ringer <craig@2ndquadrant.com>
Cc: Arcadiy Ivanov <arcadiy@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Parser extensions (maybe for 10?)
Date: Tue, 19 Apr 2016 15:32:07 +0300
Message-ID: <20160419153207.2170759e@fujitsu> (raw)
In-Reply-To: <CANP8+jLpf1_XXxBHK3jwBK6XPkap7K+E9ZYhr5yCBEJ4mNMofQ@mail.gmail.com>
References: <570C7B5A.9070309@gmail.com>
<5688.1460437831@sss.pgh.pa.us>
<CAMsr+YGfRw+k4e-GJ+eWsueAjnjGgA0a-Uuo1g8q2_u2p9tYiw@mail.gmail.com>
<6998.1460440319@sss.pgh.pa.us>
<CANP8+jLpf1_XXxBHK3jwBK6XPkap7K+E9ZYhr5yCBEJ4mNMofQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
> As Tom says, we can't easily break it down into multiple co-operating
> pieces, so lets forget that as unworkable.
I'm sorry but didn't I just demonstrate the opposite? If so it's very
easy to prove - give a counterexample. As I understand approach I
described handles cases named by Tom just fine. In fact the idea of
transforming ASTs (a.k.a metaprogramming) is successfully used by
programmers for about 50 years now.
(As a side note - I'm not a native English speaker but I believe such
type of logic is known as "argument from authority".)
> What is possible is a whole new grammar... for example if we imagine
>
> SET client_language_path = 'foo, postgresql'
>
> Works similar to search_path, but not userset. We try to parse
> incoming statements against the foo parser first, if that fails we
> try postgresql. The default setting would be simply 'postgresql', so
> no match -> syntax error.
>
> We could make that easier by making the postgresql parser a plugin
> itself. So to produce a new one you just copy the files, modify them
> as needed then insert a new record into pg_language as an extension.
>
I think its not an extension but a replacement of a grammar. This
approach implies that every extension implements a parser from scratch.
Not sure if anyone will do it in practice to change SQL syntax a little
bit.
I'm not telling that such a feature will be completely worthless. But
why not to make a step further and not to implement plugable protocols?
E.g. make PostgreSQL compatible with MySQL and/or MongoDB? Or maybe
implement SQL dialect that forbids implicit type conversion. Or add
build-in connection pooling mechanism. I wonder though if all of this
could already be implemented as an extension without any changes in
PostgreSQL core.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.alekseev@postgrespro.ru, simon@2ndQuadrant.com, tgl@sss.pgh.pa.us, craig@2ndquadrant.com, arcadiy@gmail.com
Subject: Re: Parser extensions (maybe for 10?)
In-Reply-To: <20160419153207.2170759e@fujitsu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox