Re: WIP: hooking parser

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
>

In response to

Browse pgsql-hackers by date

  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