Re: BUG #5028: CASE returns ELSE value always when type is"char" - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date
Msg-id 4A9E7510020000250002A8F8@gw.wicourts.gov
Whole thread Raw
In response to Re: BUG #5028: CASE returns ELSE value always when type is"char"  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
List pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:

> Well, unless things have changed in recent versions of the standard
> and I've missed the change, a series of characters enclosed in
> apostrophes is what the standard calls a "character string literal"
> and defines it to be be related to character based types such as
> varchar.

That still seems to be the case in the draft of the 2003 standard I
have:

<general literal> ::=
    <character string literal>
  | <national character string literal>
  | <Unicode character string literal>
  | <binary string literal>
  | <datetime literal>
  | <interval literal>
  | <boolean literal>
<character string literal> ::=
    [ <introducer><character set specification> ]
    <quote> [ <character representation>... ] <quote>
    [ { <separator> <quote> [ <character representation>... ] <quote>
}... ]

The ball's in your court to show something in the standard to say that
a character string literal is ever *not* to be taken as a character
string.

-Kevin

pgsql-bugs by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"
Next
From: Sam Mason
Date:
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"