Re: idea, proposal: only preloadable libraries (conditional load) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: idea, proposal: only preloadable libraries (conditional load)
Date
Msg-id 4136ffa0903110614g59fa631frf2771ceda7ff0bc7@mail.gmail.com
Whole thread Raw
In response to Re: idea, proposal: only preloadable libraries (conditional load)  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: idea, proposal: only preloadable libraries (conditional load)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Mar 11, 2009 at 12:56 PM, Simon Riggs <simon@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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Has anybody think about changing BLCKSZ to an option of initdb?
Next
From: Greg Stark
Date:
Subject: Re: Has anybody think about changing BLCKSZ to an option of initdb?