> 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