Re: libpq Describe Extension [WAS: Bytea and perl]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq Describe Extension [WAS: Bytea and perl]
Date: 2006-08-10 16:31:52
Message-ID: 16429.1155227512@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-novice

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> I'm leaning slightly to the fold-it-into-PQprepare way, but am by
>> no means set on that. Comments anyone?

> As a heavy user of libpq via DBD::Pg, +1 to folding in.

Another thought: I looked into the protocol description and was reminded
that Describe Statement actually returns both ParameterDescription and
RowDescription, ie, both the list of parameter datatypes and the list
of column names and types that will be returned by the eventual
execution of the statement. So another theory about how this ought to
work is that PQprepare's result PGresult ought to carry the column
name/type info where PQfname and PQftype can get them, and then we'd
have to have two new PGresult-inspection functions to pull out the
separately stored parameter-datatype info. This seems much cleaner than
overloading the meaning of PQftype, but OTOH it's yet a few more cycles
added to the execution cost of PQprepare. Anyone have a need to get the
result type info during PQprepare?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-10 16:40:46 Re: Win32 max connections bug (causing crashes)
Previous Message Merlin Moncure 2006-08-10 16:25:27 Re: Win32 max connections bug (causing crashes)

Browse pgsql-novice by date

  From Date Subject
Next Message David Fetter 2006-08-10 17:28:14 Re: libpq Describe Extension [WAS: Bytea and perl]
Previous Message Greg Sabino Mullane 2006-08-10 16:14:38 Re: libpq Describe Extension [WAS: Bytea and perl]