Re: [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG
Date
Msg-id CAJrrPGf=wSZgE19DoGmvD+vcnB1hhp6uAKf01DUB8M186z8dDA@mail.gmail.com
Whole thread Raw
In response to [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection inECPG  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Responses Re: [WIP] RE: DECLARE STATEMENT setting up a connectionin ECPG  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
List pgsql-hackers


On Thu, Mar 30, 2017 at 1:57 PM, Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com> wrote:

>+ if(connection_name == NULL)
>+ {
>+ /*
>+ * Going to here means not using AT clause in the DECLARE STATEMENT
>+ * We don't allocate a node to store the declared name because the
>+ * DECLARE STATEMENT without using AT clause will be ignored.
>+ */
>+ return true;
>+ }
>
>I am not sure that just ignore the declare statement may be wrong.
>I feel whether such case is possible? Does the preprocessor allows it?

As you pointed out, the above thing should be discussed.
The current implementation is as follows:

ECPG pre-processor allows the DECLARE STATEMENT without using AT clause.
And the following statement after DECLARE STATEMENT such as PREPARE, EXECUTE are
executed as usual on the current connection.

But there's a limitation here.
 (This limitation should be disccused earlier and be specified in the doc...
  but I didn't realize this clearly by myself, sorry)

When using DECLARE STATEMENT without AT clause
and using OPEN statement with AT clause, it doesn't work.

There's an example where you cannot fetch rows from db:
        EXEC SQL CONNECT TO db AS con;

        EXEC SQL DECLARE stmt STATEMENT;
        EXEC SQL AT con PREPARE stmt FROM :selectString;
        EXEC SQL AT con DECLARE cur CURSOR FOR stmt;
        EXEC SQL AT con OPEN cur;
         ...

This limitation looks troublesome for users,
so maybe I need to fix this implementation.

As per above test steps, it doesn't produce the results and doesn't
generate the error also. I feel this needs to be fixed.

As we are at the end of commitfest, it is better you can move it
to next one commitfest and provide an updated patch to solve the
above problem.

Regards,
Hari Babu
Fujitsu Australia

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [BUGS] Bug in Physical Replication Slots (at least9.5)?
Next
From: Michael Paquier
Date:
Subject: Re: Allow interrupts on waiting standby