Re: Could not determine data type of parameter $1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Vincent Risi <vince(at)bbd(dot)co(dot)za>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Could not determine data type of parameter $1
Date: 2006-08-30 13:05:42
Message-ID: 26409.1156943142@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Kris Jurka <books(at)ejurka(dot)com> writes:
> When given a timestamp parameter the jdbc driver does not know if it is
> going to be used a timestamp with time zone or a timestamp without time
> zone. The driver passes it to the server as an unknown data type letting
> the server figure out what to do with it. Usually you'll have
> timestampcol = ? or you're inserting into a timestamp field so the server
> can easily determine the true datatype the parameter is being used at. In
> this case since it's just being sent back to the user the server cannot
> determine the type and bails out. You need to help it along with a cast:
> "SELECT ?::timestamptz".

Hm, I wonder if we are being overly strict about this. In the
non-prepared-statement scenario, you can do

SELECT 'foo'

and the system just plays dumb and emits the string again --- it's
perfectly happy to report the datatype as UNKNOWN. Is it reasonable to
allow the same treatment for parameter symbols, or will client code just
choke anyway if it sees the parameter type come back as UNKNOWN?

regards, tom lane

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Mario Splivalo 2006-08-30 14:38:47 Catching postgres exceptions - functions returning error values?
Previous Message Dave Cramer 2006-08-30 12:36:07 Re: outOfMemoryError