Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Wheeler <david(at)wheeler(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
Date: 2002-11-20 04:42:57
Message-ID: 8765uskg1a.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Thinking about this, it occurs to me that there's no good reason why
> we couldn't allow parameter symbols ($n) to be considered type UNKNOWN
> initially.

Good idea.

> 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?

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). It would also allow us to side-step the parser for EXECUTE
parameters, which was something that a few people had requested
earlier.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-11-20 05:24:55 Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
Previous Message David Wheeler 2002-11-19 23:13:49 Re: DBD::PostgreSQL

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2002-11-20 05:24:55 Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
Previous Message ljb 2002-11-20 02:29:06 Re: Question about the postgresql protocol