Volkan YAZICI <[EMAIL PROTECTED]> writes:
> I've prepared a new patch that adds below commands to the libpq:
> /* Accessor functions for PGresParamDesc field of PGresult. */
> int PQnparams(const PGresult *res)
> int PQparamType(const PGresult *res, int param_num)
> /* Async functions. */
Volkan YAZICI <[EMAIL PROTECTED]> 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 per
On Aug 16 11:37, Tom Lane wrote:
> Volkan YAZICI <[EMAIL PROTECTED]> 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 ca
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> On Aug 16 11:37, Tom Lane wrote:
>> 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
>> statemen
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.
>
> Prep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 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 st
On Aug 10 11:35, Tom Lane wrote:
> Volkan YAZICI <[EMAIL PROTECTED]> writes:
> > [ patch to add PQdescribePrepared and PQdescribePortal ]
>
> After looking this over, I don't see the point of PQdescribePortal,
> at least not without adding other functionality to libpq. There is
> no functionality
On Thu, Aug 10, 2006 at 12:31:52PM -0400, Tom Lane wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> 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.
>
> Anoth
"Greg Sabino Mullane" <[EMAIL PROTECTED]> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 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.
- --
Greg Sabino Mullane [EMAIL PROTECTED] [EMAIL PROTECTED]
End Point Corporatio
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> [ patch to add PQdescribePrepared and PQdescribePortal ]
After looking this over, I don't see the point of PQdescribePortal,
at least not without adding other functionality to libpq. There is
no functionality currently exposed by libpq that allows creat
On Sat, Jun 24, 2006 at 02:45:33PM +0300, Volkan YAZICI wrote:
> I totally agree with the followed ugly style. But IMHO the recursive
> parsing (that is followed in pqParseInputN()) of received data is the main
> problem behind this. I think, it will even get harder everytime somebody
> try to to a
On Jun 16 08:21, Tom Lane wrote:
> Bruce Momjian writes:
> > Volkan YAZICI wrote:
> >> The problem is, AFAICS, it's not possible to distinguish between a tuple
> >> returning query (T, ..., C, Z or T, E) and a description of a portal (T,
> >> Z). Therefore, I've created a global flag (parsing_row_
Bruce Momjian writes:
> Volkan YAZICI wrote:
>> The problem is, AFAICS, it's not possible to distinguish between a tuple
>> returning query (T, ..., C, Z or T, E) and a description of a portal (T,
>> Z). Therefore, I've created a global flag (parsing_row_desc) which is
>> turned on when we receive
Volkan YAZICI wrote:
> To mention about the followed implementation, it needed some hack on
> pqParseInput3() code to make it understand if a received message is
> a reponse to a Describe ('D') query or to another tuple returning
> query. To summarize problem, there're two possible forms of a 'D'
>
Hi,
[Sending this message (first) to -hackers for discussion about the
extension and followed implementation.]
On Apr 01 09:39, Volkan YAZICI wrote:
> I've prepared a patch for the Describe <-> ParameterDescription
> messaging which is available via current extended query protocol.
Here's a writ
Hi,
On Mar 25 08:47, John DeSoi wrote:
> I have not looked at libpq in any detail, but it should have access
> to the type of all the parameters in the prepared statement. The
> Describe (F) statement in the frontend/backend protocol identifies
> the type of each parameter.
I've prepared a
17 matches
Mail list logo
