On Wed, 2009-03-11 at 14:45 +0000, Greg Stark wrote: > On Wed, Mar 11, 2009 at 2:18 PM, Simon Riggs <si...@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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
