From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: hooking parser |
Date: | 2009-02-13 09:38:54 |
Message-ID: | 162867790902130138n681039e6uf94f01b4ee174f86@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/2/13 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> Peter Eisentraut wrote:
>>
>> Tom Lane wrote:
>>>
>>> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>>>
>>>> I think what you want here is some way to define a function that takes
>>>> an arbitrary number of arguments of arbitrary type and let the function
>>>> figure everything out. I see no reason why this can't be a variant on
>>>> CREATE FUNCTION, except that of course you need to figure out some API and
>>>> function resolution details.
>>>
>>> We've already got "variadic any" functions --- the problem is to tell
>>> the parser what the function's result type will be, given a particular
>>> parameter list. I agree that hooking transformExpr is not exactly the
>>> most ideal way to attack that from a performance or complexity
>>> standpoint.
>>
>> What is the defined return type logic for the decode() function anyway?
>> If you want the full CASE-like resolution logic, it might be very hard to
>> fit that into a general system.
>
> And on top of that, decode() is supposed to do short-circuit evaluation of
> the arguments.
>
yes, you should to look so this work do transform hook very vell
regards
Pavel
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-02-13 09:41:06 | Re: WIP: hooking parser |
Previous Message | Peter Eisentraut | 2009-02-13 09:27:01 | Re: per-database locale: createdb switches |