RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE - Mailing list pgsql-hackers

From kuroda.hayato@fujitsu.com
Subject RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Date
Msg-id TYAPR01MB586690A1FC9D45446CCF28C4F5159@TYAPR01MB5866.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  ("wangsh.fnst@fujitsu.com" <wangsh.fnst@fujitsu.com>)
Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List 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


Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Michael Paquier
Date:
Subject: Re: More time spending with "delete pending"