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/tyapr01mb5866973462d17f2aebd8ebb8f5...@tyapr01mb5866.jpnprd01.prod.outlook.com [2]: https://www.postgresql.org/message-id/yoqncyfxp868z...@paquier.xyz -- Michael
signature.asc
Description: PGP signature
