> 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
signature.asc
Description: This is a digitally signed message part
