Re: plpgsql CASE statement - last version
От | Pavel Stehule |
---|---|
Тема | Re: plpgsql CASE statement - last version |
Дата | |
Msg-id | 162867790805070023p504a76dcq214a82b5b1aebd02@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql CASE statement - last version ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: plpgsql CASE statement - last version
|
Список | 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 >> >
Вложения
В списке pgsql-patches по дате отправления: