Re: WIP: hooking parser - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: hooking parser
Date
Msg-id 11002.1234371936@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: hooking parser  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: WIP: hooking parser
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2009/2/11 Tom Lane <tgl@sss.pgh.pa.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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: WIP: hooking parser
Next
From: Gianni Ciolli
Date:
Subject: Re: Optimization rules for semi and anti joins