Simon Riggs <si...@2ndquadrant.com> writes:
> On 26 February 2015 at 15:56, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I don't find that particularly attractive either. It seems quite unlikely
>> to me that anyone would actually use such a hook; replacing the whole
>> parser would be essentially unmaintainable. Nobody uses the hooks you
>> mention to replace the whole planner or whole executor --- there are
>> wrappers out there, which is a different thing altogether. But you could
>> not undo the issue at hand here without at the very least a whole new
>> copy of gram.y, which would need to be updated constantly if you wanted
>> it to keep working across more than one release.
> That's not what I see.
> Whole planner replacement is used for extensions by CitusData and NTT,
> and will definitely be used in the future for other apps.
> Whole executor replacement is also used by one extension to produce
> DDL triggers.
That sounds completely silly from here. You'd be better off maintaining
your code as a set of patches on the core code and shipping your own
binaries. It would be substantially less work to maintain, I'd think,
because otherwise you have to track every single patch made to what are
very large swaths of code. The costs of merge resolution (when your
changes specifically touch something also updated by the community) would
be about the same, but the gruntwork aspect would be considerably better.
And you'd have to be certifiably insane to ship such things as extensions
not tied to specific core binaries, anyway, so I'm not seeing an upside
in doing it like that.
Having said that, I won't stand in the way of somebody else proposing
parser hooks. I don't intend to do it myself though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
