From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | Kris Jurka <books(at)ejurka(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: tightening up on use of oid 0 |
Date: | 2004-10-13 15:20:19 |
Message-ID: | 14846.1097680819@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> - "? IS NULL" breaks if the parameter is an untyped NULL (this was the
> original issue -- in an off-list email --that made me look at this area)
Hmm. The system doesn't complain if you do "select 'z' IS NULL". It
knows that it doesn't have a hard idea about the datatype of 'z', but it
also knows that it doesn't matter much. The reason that you are seeing
a failure is that exec_parse_message() explicitly fails if any parameter
datatypes remain UNKNOWN after parsing. I made it do that because I
expected that client code would be unhappy to get UNKNOWN back as a
"resolved" parameter datatype. Would you rather get that result or
a failure?
> - Functions taking 'anyarray' or 'anyelement' don't like untyped NULLs,
> even if they are STRICT (ERROR: could not determine anyarray/anyelement
> type because input has type "unknown")
This you're just stuck with. There has to be some way to determine the
actual datatype imputed to the function result, and if you supply an
untyped parameter then there isn't. It hasn't got anything to do with
whether the parameter is NULL or not.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Mulder | 2004-10-13 15:51:30 | Free PostgreSQL Training, Philadelphia, Oct 30 |
Previous Message | Tornroth, Phill | 2004-10-13 15:04:29 | FW: Question about the postgres resultset implementation |