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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq Describe Extension [WAS: Bytea and perl]
Date: 2006-06-17 00:21:21
Message-ID: 9374.1150503681@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-novice

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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 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?

The whole thing sounds like brute force to me. Shouldn't you be adding
states to enum PGQueryClass, if you need to track what sort of Describe
you're doing?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2006-06-17 00:24:12 Re: Fabian Pascal and RDBMS deficiencies in fully implementing
Previous Message Tom Lane 2006-06-17 00:09:56 Re: MultiXacts & WAL

Browse pgsql-novice by date

  From Date Subject
Next Message Gang Cheng 2006-06-17 13:08:54 Generalized trigger function
Previous Message raulpdlr 2006-06-16 21:55:00 FATAL: IDENT authentication failed for user "soAndso", quick fix