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.
--
greg
