Re: BUG #5028: CASE returns ELSE value always when type is"char"

Поиск
Список
Период
Сортировка
От Sam Mason
Тема Re: BUG #5028: CASE returns ELSE value always when type is"char"
Дата
Msg-id 20090902193451.GA5407@samason.me.uk
обсуждение исходный текст
Ответ на 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"  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: BUG #5028: CASE returns ELSE value always when type is"char"
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: BUG #5028: CASE returns ELSE value always when type is"char"