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 29117.1251925304@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:
> Because COALESCE(NULL, NULL) has given no indication that it is
> character based, while 'x' is defined by the standard to be a
> character string literal.  The two uses of "unknown" in typing seem to
> be solving different problems.  Perhaps using the same flag for both
> is part of the problem.  The above was suggesting we differentiate.

I've always thought that having the type system treat NULL and 'foo'
alike was a feature, not a bug.  In a formal sense the type information
available is the same, ie, none.  The argument that SQL says 'foo'
must be character, so we should too, is greatly weakened by the fact
that SQL has such an impoverished set of built-in types.  If we want
to treat user-defined types as anything approaching first-class types,
we have to be pretty suspicious of that restriction.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
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"