Thread: executing prepared select, missing RowDescription info

executing prepared select, missing RowDescription info

From
Kris Jurka
Date:
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

From
Tom Lane
Date:
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

From
Christoph Haller
Date:
------------- Begin Forwarded Message -------------


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