RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
От | kuroda.hayato@fujitsu.com |
---|---|
Тема | RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE |
Дата | |
Msg-id | TYAPR01MB586690A1FC9D45446CCF28C4F5159@TYAPR01MB5866.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE |
Список | pgsql-hackers |
Dear Horiguchi-san, Thank you for reviewing! I attached new version. Sorry for delaying reply. > Since we don't allow descriptors with the same name even if they are > for the different connections, I think we can set the current > connection if any (which is set either by AT option or statement-bound > one) to i->connection silently if i->connection is NULL in > lookup_descriptor(). What do you think about this? I tried to implement. Is it correct? > connection is "conn1" at the error time. The parser relies on > output_statement and friends for connection name reset. So the rules > that don't call the functions need to reset it by themselves. Oh, I didn't notice that. Fixed. I'm wondering why a output function is not implemented, like output_describe_statement(), but anyway I put a connection reset in ecpg.addons. > Similary, the following sequence doesn't yield an error, which is > expected. > > > EXEC SQL AT conn1 DECLARE stmt STATEMENT; > > EXEC SQL AT conn2 EXECUTE stmt INTO ..; > > In this case "conn2" set by the AT option is silently overwritten with > "conn1" by check_declared_list(). I think we should reject AT option > (with a different connection) in that case. Actually this comes from Oracle's specification. Pro*C precompiler overwrite their connection in the situation, hence I followed that. But I agree this might be confused and I added the warning report. How do you think? Is it still strange? Best Regards, Hayato Kuroda FUJITSU LIMITED
Вложения
В списке pgsql-hackers по дате отправления: