Re: [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>
Cc: "Okano, Naoki" <okano(dot)naoki(at)jp(dot)fujitsu(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG
Date: 2017-03-30 06:03:53
Message-ID: CAJrrPGf=wSZgE19DoGmvD+vcnB1hhp6uAKf01DUB8M186z8dDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 30, 2017 at 1:57 PM, Ideriha, Takeshi <
ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-03-30 06:16:51 Re: Allow interrupts on waiting standby
Previous Message Kyotaro HORIGUCHI 2017-03-30 05:46:35 Re: [HACKERS] Bug in Physical Replication Slots (at least 9.5)?