Re: plpgsql's case bug?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql's case bug?
Date: 2010-03-28 04:38:03
Message-ID: 11606.1269751083@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
> <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
>> this is based on General Rules case 1 of chapter 13.6 (case statement)
>> but i don't think that behaviour is the meaning of that Rule. Even if
>> it is, the exception should be: "case not found for case statement"
>> and not just "case not found"
>>
>> General Rules
>> 1) Case:
>> a) If the <search condition> of some <searched case statement when
>> clause> in a <case statement> is
>> True, then let SL be the <SQL statement list> of the first
>> (leftmost) <searched case statement when
>> clause> whose <search condition> is True.
>> b) If the <case statement> simply contains a <case statement else
>> clause>, then let SL be the <SQL statement
>> list> of that <case statement else clause>.
>> c) Otherwise, an exception condition is raised: case not found for
>> case statement, and the execution of
>> the <case statement> is terminated immediately.

> It seems odd to require a dummy ELSE clause that does nothing just to
> avoid having an exception thrown, but I'm not sure what else to make
> of the quoted portion of the spec. What do you think it's saying?

I concur that we seem to be implementing the behavior the spec requires.

As for the spelling of the error message, I don't believe that the spec
intends to mandate any particular spelling of the text, only the value
of the SQLSTATE code. Were this not so, any translation of error
messages would be a spec violation all by itself.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-03-28 05:15:32 Re: join removal
Previous Message Tom Lane 2010-03-28 04:19:39 Re: join removal