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)  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
Следующее
От: Tom Lane
Дата:
Сообщение: Geometry test on NetBSD (was Re: RC1?)