Re: A problem presentaion about ECPG, DECLARE STATEMENT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "'Peter Eisentraut'" <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A problem presentaion about ECPG, DECLARE STATEMENT
Date: 2019-09-20 16:59:27
Message-ID: 26660.1568998767@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> writes:
>> 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.

> I see, I'll propose this at the next commitfest.
> But I'm now considering this commit should be reverted in order to avoid
> the confusion.

Per this discussion, I've reverted DECLARE STATEMENT out of v12 and HEAD
branches.

One thing that could use more eyeballs on it is the changes in
ecpg_register_prepared_stmt(); that was added after DECLARE STATEMENT
so there was no prior state to revert to, and I had to guess a bit.
What I guessed, seeing that the lone caller of that function is
already using stmt->connection, was that it was completely bogus
for ecpg_register_prepared_stmt() to be doing its own new connection
lookup and it should just use stmt->connection. But I might be wrong
since I'm not too clear about where connection lookups are supposed
to be done in this library.

Another comment is that this was one of the more painful reverts
I've ever had to do. Some of the pain was unavoidable because
there were later commits (mostly the PREPARE AS one) changing
adjacent code ... but a lot of it was due to flat-out sloppiness
in the DECLARE STATEMENT patch, particularly with respect to
whitespace. Please run the next submission through pgindent
beforehand. Also please pay attention to the documentation cleanups
that other people made after the initial patch. We don't want to
have to repeat that cleanup work a second time.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-09-20 17:08:31 Re: subscriptionCheck failures on nightjar
Previous Message Alvaro Herrera 2019-09-20 16:49:47 Re: [HACKERS] CLUSTER command progress monitor