On Wed, 2009-03-11 at 14:45 +0000, Greg Stark wrote:
> On Wed, Mar 11, 2009 at 2:18 PM, Simon Riggs <simon@2ndquadrant.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.comPostgreSQL Training, Services and Support
