Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Date
Msg-id 145703eb7ae99512b4e7885b1b90714493b3855c.camel@postgresql.org
Whole thread Raw
In response to Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  (Michael Paquier <michael@paquier.xyz>)
Responses RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
> Okay.  So you mean to change DESCRIBE and DEALLOCATE to be able to
> handle cached connection names, as of [1]?  For [DE]ALLOCATE, I agree

Yes, at least technically. I think DESCRIBE should accept the cached
connection name, although it won't really matter.

> that it could be a good thing.  declare.pgc seems to rely on that
> already but the tests are incorrect as I mentioned in [2].  For
> DESCRIBE, that provides data about a result set, I find the
> assignment
> of a connection a bit strange, and even if this would allow the use
> of
> the same statement name for multiple connections, it seems to me that
> there is a risk of breaking existing applications.  There should not
> be that many, so perhaps that's fine anyway.

I don't think we'd break anything given that DECLARE STATEMENT is new.
Also please keep in mind that you can use EXEC SQL AT ... DESCRIBE ...;
already anyway. Again, not very meaningful but why should we accept a
connection one way but not the other?

Michael

--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org

Attachment

pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Next
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] test/ssl: rework the sslfiles Makefile target