Re: libpq Describe Extension [WAS: Bytea and perl] - Mailing list pgsql-hackers

From Volkan YAZICI
Subject Re: libpq Describe Extension [WAS: Bytea and perl]
Date
Msg-id 20060811130548.GE1432@alamut.tdm.local
Whole thread Raw
In response to Re: libpq Describe Extension [WAS: Bytea and perl]  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: libpq Describe Extension [WAS: Bytea and perl]
List pgsql-hackers
On Aug 11 12:51, Greg Sabino Mullane wrote:
> > think it would be quite handy to be able to gather information about
> > a prepared stmt in later phases of an application. For instance one
> > might need to get the parameter and row types of a prepared query
> > that he/she isn't created.
> 
> 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.

> >> Anyone have a need to get the result type info during PQprepare?
> 
> > I don't think so. And if one would ever need such an information, can
> > reach it quite easily via PQdescribePrepared().
> 
> That's a good point, however, along with your other arguments. :) I
> could live with either way.

I'm just declined to break current PQprepare() or to introduce new
PGresult-processor functions for a feature (IMHO) that needs its own
function. But the general use case is the main fact that'll say the last
word.


Regards.


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Bison Version
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: Bison Version