From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Greg Stark <stark(at)enterprisedb(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: idea, proposal: only preloadable libraries (conditional load) |
Date: | 2009-03-11 15:05:39 |
Message-ID: | 1236783939.28644.159.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2009-03-11 at 14:45 +0000, Greg Stark wrote:
> On Wed, Mar 11, 2009 at 2:18 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> >> 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.
> >
> > If it's a plugin that "someone" isn't any concern of ours. External
> > projects can keep up with releases, or specific customer implementations
> > may simply choose to standardise on one release and go with that.
>
> That's not what I mean. I mean, for example, if someone adds a field
> to any of the structss in parsenodes.h to implement a new feature. The
> old parser would have to know how to initialize that field correctly
> to avoid triggering that new feature or trigger it in a manner
> compatible with the old version's implicit behaviour.
>
> The last few commits to that file include Tom's commit to handle ALTER
> TABLE SET WITHOUT OIDS, Alvaro's commit to handle reloptions with
> qualifiers, Stephen Frost's patch to support column-level privileges,
> Heikki's commit to handle vacuum_freeze_table_age, etc.
>
> Every one of these commits would have had to adjust every single old
> parser to generate the correct data for the changed nodes.
>
> The parser isn't a separable module interacting with the rest of the
> system through a static interface. It's closely in bed with the rest
> of the system implementing the syntax it's parsing. Every feature the
> parser can parse has to be communicated to the backend code
> implementing the feature so it has to have a corresponding knob in the
> interface between the parser and the rest of the system.
It would be a matter for a plugin designer how they did that. If the new
parser involved just some changes in specific areas, then presumably you
would design it as a drop through parser: handle any special cases or
drop through to normal Postgres parser.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-03-11 15:19:34 | Re: parallel restore fixes |
Previous Message | Greg Stark | 2009-03-11 14:45:31 | Re: idea, proposal: only preloadable libraries (conditional load) |