Обсуждение: executing prepared select, missing RowDescription info

Поиск
Список
Период
Сортировка

executing prepared select, missing RowDescription info

От
Kris Jurka
Дата:
When executing a prepared select statement, the returned RowDescription
protocol message does not have any information for the table oid or column
position.  Running the equivalent select without prepare provides this
information, so I don't see why the act of preparing and executing the
statement removes this valuable data.  Any insight on why it isn't there 
or how to fix it?

Kris Jurka


Re: executing prepared select, missing RowDescription info

От
Tom Lane
Дата:
Kris Jurka <books@ejurka.com> writes:
> When executing a prepared select statement, the returned RowDescription
> protocol message does not have any information for the table oid or column
> position.  Running the equivalent select without prepare provides this
> information, so I don't see why the act of preparing and executing the
> statement removes this valuable data.  Any insight on why it isn't there 
> or how to fix it?

Fixing this would be a tad messy, because the information is not
propagated up through a utility-statement Portal.  I guess I would ask
why you're using EXECUTE at all; it's considerably less efficient than
invoking the prepared statement via the protocol-level operation for
doing so (Bind, then Execute).
        regards, tom lane


Re: executing prepared select, missing RowDescription info

От
Christoph Haller
Дата:
------------- Begin Forwarded Message -------------


Re: [HACKERS] executing prepared select, missing RowDescription info

От
Дата:
>
> Kris Jurka <books@ejurka.com> writes:
> > When executing a prepared select statement, the returned RowDescription
> > protocol message does not have any information for the table oid or column
> > position.  Running the equivalent select without prepare provides this
> > information, so I don't see why the act of preparing and executing the
> > statement removes this valuable data.  Any insight on why it isn't there
> > or how to fix it?
>
> Fixing this would be a tad messy, because the information is not
> propagated up through a utility-statement Portal.  I guess I would ask
> why you're using EXECUTE at all; it's considerably less efficient than
> invoking the prepared statement via the protocol-level operation for
> doing so (Bind, then Execute).
>
>             regards, tom lane
>
And how would I do this more efficient "Bind, then Execute" using libpq?
TIA

Regards, Christoph


------------- End Forwarded Message -------------