Date: Tue, 19 Apr 2016 15:32:07 +0300
From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Craig Ringer <craig@2ndquadrant.com>,
 Arcadiy Ivanov <arcadiy@gmail.com>, PostgreSQL Hackers
 <pgsql-hackers@postgresql.org>
Subject: Re: Parser extensions (maybe for 10?)
Message-ID: <20160419153207.2170759e@fujitsu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

> 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