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

From Bruce Momjian
Subject Re: libpq Describe Extension [WAS: Bytea and perl]
Date
Msg-id 200606162000.k5GK0wO27800@candle.pha.pa.us
Whole thread Raw
In response to Re: libpq Describe Extension [WAS: Bytea and perl]  (Volkan YAZICI <yazicivo@ttnet.net.tr>)
Responses Re: libpq Describe Extension [WAS: Bytea and perl]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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'
> response:
> 
>  1. Description of a prepared statement: t, T, Z
>  2. Description of a portal: T, Z
> 
> 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 a 'T' and turned off if we receive a 'C' or
> 'E'. It's a kind of ugly method but the only solution I could come up
> with.

The problem with this solution is that it is not thread-safe.  Perhaps
you can use a per-PGconn boolean?

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if