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