Dear Michael, > I have been chewing on this comment and it took me some time to > understand what you meant here.
Sorry... But your understanding is correct. > It is true that the ecpglib part, aka > all the routines you are quoting above, don't rely at all on the > connection names. However, the preprocessor warnings generated by > drop_descriptor() and lookup_descriptor() seem useful to me to get > informed when doing incorrect descriptor manipulations, say on > descriptors that refer to incorrect object names. So I would argue > for keeping these. Thank you for giving your argument. I will keep in the next patch. > And indeed, I would have expected those queries introduced by ad8305a > to pass. So a backpatch down to v14 looks adapted. Yeah. I think, at least, DEALLOCATE statement should use the associated connection. > I am going to need more time to finish evaluating this patch, but it > seems that this moves to the right direction. The new warnings for > lookup_descriptor() and drop_descriptor() with the connection name are > useful. Should we have more cases with con2 in the new set of tests > for DESCRIBE? Thanks. OK, I'll add them to it. > By the way, as DECLARE is new as of v14, I think that the interactions > between DECLARE and the past queries qualify as an open item. I am > adding Michael Meskes in CC. I got to wonder how much of a > compatibility break it would be for DEALLOCATE and DESCRIBE to handle > EXEC SQL AT in a way more consistent than DECLARE, even if these are > bounded to a result set, and not a connection. I already said above, I think that DEALLOCATE statement should follow the linked connection, but I cannot decide about DESCRIBE. I want to ask how do you think. Best Regards, Hayato Kuroda FUJITSU LIMITED
