Re: idea, proposal: only preloadable libraries (conditional load)

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Greg Stark <stark(at)enterprisedb(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: idea, proposal: only preloadable libraries (conditional load)
Date: 2009-03-11 15:05:39
Message-ID: 1236783939.28644.159.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2009-03-11 15:19:34 Re: parallel restore fixes
Previous Message Greg Stark 2009-03-11 14:45:31 Re: idea, proposal: only preloadable libraries (conditional load)