Re: plpgsql CASE statement - last version - Mailing list pgsql-patches

From Pavel Stehule
Subject Re: plpgsql CASE statement - last version
Date
Msg-id 162867790805070023p504a76dcq214a82b5b1aebd02@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql CASE statement - last version  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: plpgsql CASE statement - last version
List pgsql-patches
Hello

I am sending little bit smarter version - without redundant parsing.
When test expression is defined, then expressions in WHEN part are
modified like

$x in ( origin_expression )

$x is referenced to invisible *case* variable that carries result of
test expression.
Regards
Pavel Stehule



2008/5/3 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
> 2008/5/3 Tom Lane <tgl@sss.pgh.pa.us>:
>> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>>> 2008/5/2 Heikki Linnakangas <heikki@enterprisedb.com>:
>>>> How about taking a completely different strategy, and implement the
>>>> CASE-WHEN construct fully natively in plpgsql, instead of trying to convert
>>>> it to a single SQL CASE-WHEN expression? It's not a very good match anyway;
>>
>>> It was first variant. It's  simpler for parsing and slower for
>>> execution :(. It means more than once expression evaluation and for
>>> simple case value casting and comparation.
>>
>> I agree with Heikki: this patch is seriously ugly, and "slower for
>> execution" isn't a good enough reason for saddling us with having
>> to maintain such a kluge in the parser.
>>
>> I don't really see why you should need to have multiple expression
>> evaluations, anyhow.  Can't you evaluate the test expression once
>> and inject its value into the comparisons using CaseTestExpr,
>> the same way the core CASE-expression code works?
>>
>>
>
> I have to look on this way.
>
> Regards
> Pavel Stehule
>
>                   regards, tom lane
>>
>

Attachment

pgsql-patches by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: Map forks (WIP)
Next
From: Peter Eisentraut
Date:
Subject: Re: column level privileges