From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(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:41:29 |
Message-ID: | 3F205289.1050702@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Stephan Szabo wrote:
> On Thu, 24 Jul 2003, Joe Conway wrote:
>>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?
good point -- no pun intended ;)
>
> 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.
>
Hmm, this sounds like yet another reason for UNKNOWN[]. Specifically
what I wanted to do was create a function that would give me a NULL if
any arguments to my ARRAY[] expression were NULL. But the change Tom
suggested (i.e. ARRAY[NULL,...] evaluates to NULL) gives me that without
needing the function, so probably that is the best answer.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-07-24 21:52:07 | Re: php with postgres |
Previous Message | Stephan Szabo | 2003-07-24 21:28:27 | Re: odd behavior/possible bug |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-07-24 22:31:48 | array expression NULL fix [was: [HACKERS] odd behavior/possible bug] |
Previous Message | Stephan Szabo | 2003-07-24 21:28:27 | Re: odd behavior/possible bug |