Re: tightening up on use of oid 0

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

In response to

Browse pgsql-jdbc by date

  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