Re: odd behavior/possible bug

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: odd behavior/possible bug
Date: 2003-07-24 21:28:27
Message-ID: 20030724141617.O4895-100000@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


On Thu, 24 Jul 2003, Joe Conway wrote:

> Tom Lane wrote:
> > Joe Conway <mail(at)joeconway(dot)com> writes:
> >>So far so good. But look at this one:
> >>regression=# select dwarray(null,null);
> >>ERROR: cannot determine ANYARRAY/ANYELEMENT type because input is UNKNOWN
> >
> > That seems correct to me. What would you expect to happen? There's no
> > type we could assign as the function's actual return type.
>
> I see your point, but mine was that in this case I'd like a NULL
> returned and I don't really care about the type. ISTM that NULL should
> be able to morph into any type it needs to.

I don't think that's necessarily true.
As a potentially absurd example, do we want
select CAST( CAST( NULL as DATE ) as POINT );
to succeed when dates aren't convertable to points?

The case of func(anyelement, anyelement) returns anyarray could
potentially return some kind of "array of unknown (but single) type"
when presented with unknown inputs. I'm not sure what use that'd be
unless you are allowed to convert it into something else, though.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2003-07-24 21:41:29 Re: odd behavior/possible bug
Previous Message Marcus Brger 2003-07-24 21:17:01 Re: php with postgres

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2003-07-24 21:41:29 Re: odd behavior/possible bug
Previous Message Tom Lane 2003-07-24 21:13:33 Re: odd behavior/possible bug