| 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: | Whole Thread | Raw Message | 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 |