On Mon, Aug 09, 2021 at 10:50:29PM +0200, Michael Meskes wrote:
>> On the substance of the issue, one question that I have reading over
>> this thread is whether there's really a bug here at all. It is being
>> represented (and I have not checked whether this is accurate) that
>> the
>> patch affects the behavior of DECLARE, PREPARE, and EXECUTE, but not
>> DESCRIBE, DEALLOCATE, DECLARE CURSOR .. FOR, or CREATE TABLE AS
>> EXECUTE. However, it also seems that it's not entirely clear what the
>> behavior ought to be in those cases, except perhaps for DESCRIBE. If
>> that's the case, maybe this doesn't really need to be an open item,
>> and maybe we don't therefore need to talk about whether it should be
>> reverted. Maybe it's just a feature that supports certain things now
>> and in the future, after due reflection, perhaps it will support
>> more.
>
> The way I see it we should commit the patch that makes more statements
> honor the new DECLARE STATEMENT feature. I don't think we can change
> anything for the worse by doing that. And other databases are not
> really strict about this either.
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
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.
[1]:
https://www.postgresql.org/message-id/TYAPR01MB5866973462D17F2AEBD8EBB8F51F9@TYAPR01MB5866.jpnprd01.prod.outlook.com
[2]: https://www.postgresql.org/message-id/YOQNCyfxp868zZUV@paquier.xyz
--
Michael
