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 3e29e0176882245c89d18955b9d8f1d5a6425345.camel@postgresql.org
Whole thread Raw
In response to RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
Dear Kuroda-san,

> I perfectly missed mails and 8/9 was a national holiday.
> I must apologize about anything. Very sorry for inconvenience.

No need to, non of it is your fault.

> I summarize the thread.

Thank you so much, this is very, very helpful.

> As you might know DECLARE STATEMENT has been added from PG14, but I
> found that connection-control feature cannot be used for DEALLOCATE
> and DESCRIBE statement (More details, please see patches or ask me).
> But we have a question - what statement should use the associated
> connection? Obviously DEALLOCATE statement should follow the linked
> connection because the statement uses only one sql identifier. In
> DESCRIBE or any other descriptor-related statements, however, I think
> it is non-obvious because they have also descriptor-name. Currently I
> made patches that includes about DESCRIBE, but I'm wondering this
> approach is correct. I want you to ask your opinion about the scope
> of
> DECLARE STATEMENT.

I've been reading through quite a few documents to come up with a good
reason one way or the other, but as you already pointed out yourself,
other database systems seem to not be consequent about the usage
either. 

Unfortunately I didn't find my copy of the SQL standard. But then I
kind of doubt it has much to say about this particular issue.

Anyway, I'm currently leaning towards including DESCRIBE in the list of
statements that are influenced by DECLARE STATEMENT. My reason is that
DESCRIBE can be issued with an AT clause already, regardless whether it
makes sense or not. Or in other words, if we allow it to get a
connection name one way, why should we forbid the other way. To me this
seems to be more confusing than the current situation.

The alternative would be to forbid using an AT clause with DESCRIBE,
which would definitely be a compatibility change, although, again, not
a functional one.

> Coding is not hard hence I think we can fix this until the end of
> Sep.
> if we set a policy correctly and have reviewers.

Fully agreed. That's why a short glance at the patch didn't suffice to
answer this. I didn't see any issues with the patch so far. Please send
it to me once its finished (or is it already?) and I'll give it a run,
too.

Hopefully I caught up on all emails and didn't miss parts of the
thread.

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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?
Next
From: Peter Geoghegan
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE