Re: idea, proposal: only preloadable libraries (conditional load)
От | Simon Riggs |
---|---|
Тема | Re: idea, proposal: only preloadable libraries (conditional load) |
Дата | |
Msg-id | 1236783939.28644.159.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: idea, proposal: only preloadable libraries (conditional load) (Greg Stark <stark@enterprisedb.com>) |
Список | 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@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
В списке pgsql-hackers по дате отправления: