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

From Sam Mason
Subject Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date
Msg-id 20090902193451.GA5407@samason.me.uk
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>)
Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
> Sam Mason <sam@samason.me.uk> wrote:
> > If we did follow Kevin's request directly, should we also be
> > specifying the type of NULL?
>
> I don't *think* the SQL standard requires that, and barring that I
> don't see any compelling reason to type NULL.

I've just realized that either I'm missing your point entirely (it's
happened before :) or this ignores the point entirely.  PG wants to
assign types to every expression, whether this expression will evaluate
to a NULL value at run-time or not is immaterial in this regard.  I
think SQL wants to do the same, but I don't have as much conviction as
Tom here.  Once we're ascribing types to expressions then whether it
happens to contain the literal "1", "'txt'" or "NULL" we're committed to
giving it some type---the only question is which one.  We thus need to
type expressions consisting of just NULL constants.

A fun puzzle to base any inductive solution on is what type to ascribe
to the following:

  CREATE VIEW v (c) AS
    SELECT NULL;

PG allows it, but the resulting view seems somewhat unusable.

--
  Sam  http://samason.me.uk/

pgsql-bugs by date:

Previous
From: Sam Mason
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"