Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
От | Tom Lane |
---|---|
Тема | Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL) |
Дата | |
Msg-id | 28501.1037769895@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL) (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: