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
