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.
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 |
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 |