To: Neil Conway <neilc@samurai.com>
Cc: David Wheeler <david@wheeler.net>, pgsql-hackers@postgreSQL.org
Subject: Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL) 
In-reply-to: <8765uskg1a.fsf@mailbox.samurai.com> 
References: <A3F94BB8-FB12-11D6-93B3-0003931A964A@wheeler.net>
	<118.1037638710@sss.pgh.pa.us> <8765uskg1a.fsf@mailbox.samurai.com>
Comments: In-reply-to Neil Conway <neilc@samurai.com>
	message dated "19 Nov 2002 23:42:57 -0500"
Date: Wed, 20 Nov 2002 00:24:55 -0500
Message-ID: <28501.1037769895@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Neil Conway <neilc@samurai.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> This form of PREPARE would presumably need some way of reporting back
>> the types it had determined for the symbols; anyone have a feeling for
>> the appropriate API for that?

> Why would this be needed? Couldn't we rely on the client programmer to
> know that '$n is of type foo', and then pass the appropriately-typed
> data to EXECUTE?

I don't think so.  You may as well ask why we waste bandwidth on passing
back info about the column names and types of a SELECT result ---
shouldn't the client know that already?  There are lots of middleware
layers that don't know it, or at least don't want to expend a lot of
code on trying to deduce it.

> If we *do* need an API for this, ISTM that by adding protocol-level
> support for PREPARE/EXECUTE, this shouldn't be too difficult to do
> (and analogous to the way we pass back type information for SELECT
> results).

I'm not sure what you mean by protocol-level support, but the one idea
I had was to return a table (equivalent to a SELECT result) listing
the parameter types.  This would not break libpq, for example, so
arguably it's not a protocol change.  But if you think the recent
changes in how EXPLAIN returns its results are a protocol change, then
yeah it's a protocol change ...

			regards, tom lane