A problem presentaion about ECPG, DECLARE STATEMENT

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A problem presentaion about ECPG, DECLARE STATEMENT

kuroda.hayato@fujitsu.com
Dear ALL,

I want to report and consult about DECLARE STATEMENT.
This feature, committed last February, has some bugs.

* This is not thread-independent.
* If some cursors are declared for the same SQL identifier,
  only one cursor you declared at last is enabled.
* This syntax does not have oracle compatibility.

In order to modify bugs, I think many designs, implementations,
and specifications should be changed.
Any operations will be done at the preprocessor process, like #define
macro in C.

It will take about 2 or 3 weeks to make a patch.
Is it acceptable for PG12?

Best Regards,

Hayato Kuroda
FUJITSU LIMITED
E-Mail:[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: A problem presentaion about ECPG, DECLARE STATEMENT

Michael Meskes-3
Hi Kuroda-san,

> This feature, committed last February, has some bugs.
> ...
> * This syntax does not have oracle compatibility.

This in itself is not a bug. If the syntax is not standard compliant,
then it's a bug. That of course does not mean we would not like to be
Oracle compatible where possible.

> In order to modify bugs, I think many designs, implementations,
> and specifications should be changed.

I hope the authors of said patch speak up and explain why they
implemented it as is.

> Is it acceptable for PG12?

In general absolutely.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL



Reply | Threaded
Open this post in threaded view
|

Re: A problem presentaion about ECPG, DECLARE STATEMENT

Tom Lane-2
Michael Meskes <[hidden email]> writes:
> Hi Kuroda-san,
>> In order to modify bugs, I think many designs, implementations,
>> and specifications should be changed.

> I hope the authors of said patch speak up and explain why they
> implemented it as is.

>> Is it acceptable for PG12?

> In general absolutely.

It seems far too late to be considering any major rewrite for v12;
even assuming that there was consensus on the rewrite being an
improvement, which I bet there won't be.

"Two or three weeks from now" we'll be thinking about pushing 12.0
out the door.  We can't be accepting major definitional changes
at that point.

If a solid case can be made that ECPG's DECLARE STATEMENT was done
wrong, we'd be better off to just revert the feature out of v12
and try again, under less time pressure, for v13.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: A problem presentaion about ECPG, DECLARE STATEMENT

Michael Meskes-3
> > > Is it acceptable for PG12?
> > In general absolutely.
>
> It seems far too late to be considering any major rewrite for v12;
> even assuming that there was consensus on the rewrite being an
> improvement, which I bet there won't be.

Oops, I read 13. Yes, it's obviously way too late for 12. Sorry for the
noise.

In this case I'd like to details about what is wrong with the
implementation.

Thanks.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL



Reply | Threaded
Open this post in threaded view
|

Re: A problem presentaion about ECPG, DECLARE STATEMENT

Peter Eisentraut-6
On 2019-09-11 18:04, Michael Meskes wrote:

>>>> Is it acceptable for PG12?
>>> In general absolutely.
>>
>> It seems far too late to be considering any major rewrite for v12;
>> even assuming that there was consensus on the rewrite being an
>> improvement, which I bet there won't be.
>
> Oops, I read 13. Yes, it's obviously way too late for 12. Sorry for the
> noise.
>
> In this case I'd like to details about what is wrong with the
> implementation.

I tried finding some information about where the idea for this statement
came from but couldn't find any.  The documentation references Oracle
and DB2, and while they indeed do have this statement, it doesn't seem
to be used for the same purpose.  The only purpose in ECPG appears to be
to associate a statement with a connection, but for example the DB2
implementation doesn't even have the AT clause, so I don't see how that
could be the same.

Moreover, I've been wondering about the behavior detail given in the
table at
<https://www.postgresql.org/docs/devel/ecpg-sql-declare-statement.html>.
 In scenario 3, the declare statement says con1 but the subsequent
dynamic statement says con2, and as a result of that, con1 is used.
This is not intuitive, I'd say, but given that there is no indication of
where this statement came from or whose idea it follows, it's unclear
how to evaluate that.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services