Re: WIP: hooking parser

2009/2/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2009/2/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> This strikes me as next door to useless, because it can only handle
>>> things that look like valid expressions to the existing grammar.
>>> So pretty much all you can do is weird sorts of functions, which are
>>> already accommodated at less effort with existing features such as
>>> function overloading.
>
>> Usually we don't need change syntax. But we need to control of
>> coercion stage. I afraid so function overloading is bad when there lot
>> of combination, and polymorphic functions are not enough.
>> for some cases we need more polymorphic types - anyelement1,
>> anyelement2, anyarray1, ...
>
> Well, then we should go fix those things.
>

I am for it, and I doing on it.

> A hook function whose purpose is to fundamentally change query semantics
> strikes me as a very dangerous thing anyway, because your queries either
> stop working or suddenly do something completely different if the hook
> happens not to be loaded. The hooks we've accepted to date are intended
> for either monitoring or experimentation with planner behavior, neither
> of which will change query semantics.
>

I agree, and I understand well this risk. But still it is better and
wide used than custom patching. Look on executor hook. There are only
three cases - useful cases. It is some corner, that is far for general
using (integrating into core) and too sugar for ignore it for ever.
It's possibility, nothing less, nothing more.

regards
Pavel Stehule

> regards, tom lane
>