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:
>> some years ago there was some plans about parser's extensibility. I am
>> able write bison extensions, but I thing, so lot of work should be
>> done via hooking of transform stage.
>
> 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, ...

>
> A hook check in that particular place is not going to have negligible
> performance impact, since it's going to be hit tens or hundreds or
> thousands of times per query rather than just once. So it's going to
> require more than a marginal use case to persuade me we ought to have
> it.

Because this stage isn't repeated (I don't expect bigger performance
impact), it's similar to other's hooks. But, sure, wrong hook should
do strange things. It's risk.

+ argument - it increase customisability and allows gentle syntax
tuning. Function decode is first sample from today morning.

regards
Pavel Stehule

>
> regards, tom lane
>