Re: plpgsql's case bug? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: plpgsql's case bug?
Date
Msg-id 11606.1269751083@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpgsql's case bug?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: plpgsql's case bug?
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
> <jcasanov@systemguards.com.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: join removal
Next
From: Tom Lane
Date:
Subject: Re: join removal