On Wed, Mar 11, 2009 at 12:56 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > In the longer term it will be very useful to have the ability to support > multiple language variants, including older PostgreSQL syntax to allow > legacy systems to work with Postgres at the same time as allowing new > development to continue.
So I think having multiple parsers for different versions of Pg backwards compatibility is an awful idea. It would be a huge maintenance headache since every time we change a structure that the parser works someone would have to maintain all those compatibility parsers. And it's very rare that we make non-backwards compatible changes to the grammar with the exception of adding new reserved keywords. However that last thought led me to an interesting idea. We could fairly easily support SQL which used keywords which we later reserved. We could do this by marking each keyword in keywords.c with a version number that introduced it. Then have a guc which tells the lexer which version to target -- any keywords introduced after the desired version can just be passed up as regular urecognized identifiers. That would allow us to add new keywords more freely -- I think still not liberally since we would rather people not be forced to decide between new features and a working application. Hm, actually I see a fly in the ointment -- we often upgrade keywords from one kind of reservedness to another. That would mean we wouldn't be able to handle something like WITH which was previously some flavour of unreserved keyword and later became reserved. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
