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

From Tom Lane
Subject Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date
Msg-id 29742.1251927877@sss.pgh.pa.us
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"  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> I think that the current approach leaves a small number of corner
> cases where we break SQL compliance.  I think it's worthwhile trying
> to fix that.  Whether that's best done by identifying the individual
> corners and fixing them independently as aberrations, or implementing
> some changes which provide the PostgreSQL extensions in a way that
> doesn't tend to break standard usage (and of course has little or no
> impact on current PostgreSQL users), is beyond my ken.

It's certainly worth looking into.  I would not want to prejudge how
to fix such issues; I think the best way to proceed would be to create
a list of the problems first.

One other point worth making is that we don't always consider SQL
compliance to be a hard requirement that trumps every other
consideration.  An example is case-folding of identifiers; it's
been pretty well agreed that between readability and backwards-
compatibility considerations, we simply aren't going to switch over
to doing it exactly like the spec.  So any proposed tweaks in this area
would be considered as tradeoffs between better spec compliance and
other goals.

            regards, tom lane

pgsql-bugs by date:

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