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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date: 2009-09-03 01:21:55
Message-ID: 603c8f070909021821u5c704c3fu4b5c8a37d596da@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Sep 2, 2009 at 3:34 PM, Sam Mason<sam(at)samason(dot)me(dot)uk> wrote:
> On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
>> Sam Mason <sam(at)samason(dot)me(dot)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;

'a of course.

...Robert

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Keith Cascio 2009-09-03 01:22:35 BUG #5032: unexpected syntax error for plpgsql function returns table
Previous Message Mark Douglas 2009-09-02 23:07:16 BUG #5031: DATE_TRUNC returns the wrong value when specifying MONTH