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. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers