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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq Describe Extension [WAS: Bytea and perl]
Date: 2006-08-16 15:37:26
Message-ID: 20369.1155742646@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-novice

Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr> writes:
> On Aug 11 12:51, Greg Sabino Mullane wrote:
>> Prepared statements are not visible nor survivable outside of your
>> session, so this doesn't really make sense. If your application needs
>> the information, it can get it at prepare time.

> What about persistent connections? Actually, I can give lots of corner
> cases to support my idea but they're not that often used. I think, as
> long as we'll break compatibility, placing Describe facility in the
> PQprepare() is not the way to go.

I think this viewpoint has pretty much carried the day, so the
PQdescribe functions should remain separate. However, it still seems
to me that it'd be a shame if PQdescribePrepared couldn't return the
statement's output column types, seeing that the backend is going to
pass that info to us anyway. So I propose storing the parameter type
info in a new section of a PGresult struct, and adding new PGresult
accessor functions PQnparams, PQparamtype (or maybe PQptype to follow
the existing PQftype precedent more closely) to fetch the parameter type
info. The existing functions PQnfields etc will fetch output-column
info. Aside from being more functional, this definition maintains the
principle of least surprise, in that the interpretation of a PGresult
from Describe isn't fundamentally different from a PGresult from a
regular query.

We also need async versions PQsendDescribePrepared and
PQsendDescribePortal, as I mentioned before.

Anyone have different suggestions for the names of these functions?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-08-16 15:41:18 Re: [HACKERS] Forcing current WAL file to be archived
Previous Message Tom Lane 2006-08-16 15:17:46 Re: CREATE INDEX ... ONLINE

Browse pgsql-novice by date

  From Date Subject
Next Message Jasbinder Bali 2006-08-16 15:40:40 Re: [NOVICE] DB insert Error
Previous Message Keith Worthington 2006-08-16 15:23:00 Re: COPY command