On Wed, Aug 25, 2021 at 05:10:57AM +, wangsh.f...@fujitsu.com wrote:
> Delete first if statement, patch attached.
Indeed, this looks like a mismerge. I'll apply that in a bit.
Funnily, Coverity did not mention that.
--
Michael
signature.asc
Description: PGP signature
Hi,
I find in ecpg.header, the source:
> if (connection)
> if (connection && strcmp(ptr->connection, connection)
> != 0)
The first if statement is useless. And in fix-ecpg-tests.patch:
>- if (connection)
>-
Hi,
Sorry for being late. I had a vaccination.
I'm not sure about the rule that stderr should be removed
even if the pre-compiling state, but anyway I agree that
the warned case is not expected.
The wrong message is perfectly fault...
I confirmed your commit and I think it's OK. Thanks!
Best Re
On Tue, Aug 17, 2021 at 03:34:28PM +0900, Michael Paquier wrote:
> On Mon, Aug 16, 2021 at 12:06:16PM +0200, Michael Meskes wrote:
>> You patch removes the warning but by doing that also removes the
>> feature that is being tested.
>
> Oops. If kept this way, this test scenario is going to need a
On Mon, Aug 16, 2021 at 12:06:16PM +0200, Michael Meskes wrote:
> You patch removes the warning but by doing that also removes the
> feature that is being tested.
Oops. If kept this way, this test scenario is going to need a comment
to explain exactly that.
> I'm not sure what's the best way to
> > (1) There should be no output to stderr in the tests. Why isn't
> > this
> > message being caught and redirected to the normal test output file?
>
> These are generated during the compilation of the tests with the
> pre-processor, so that's outside the test runs.
This is actually a deeper is
On Wed, Aug 11, 2021 at 10:41:59PM +0200, Michael Meskes wrote:
> I'm not sure I understand. Any usage of DECLARE STATEMENT makes the
> file need the current version of ecpg anyway. On the other hand
> DEALLOCATE did not change its behavior if no DECLARE STATEMENT was
> issued, or what did I miss?
On Sat, Aug 14, 2021 at 11:08:44PM -0400, Tom Lane wrote:
> Please do something about that.
>
> (1) There should be no output to stderr in the tests. Why isn't this
> message being caught and redirected to the normal test output file?
These are generated during the compilation of the tests with
Michael Meskes writes:
> I will commit the patch(es). Thanks.
This commit appears to be responsible for new noise on stderr
during check-world:
$ make -s check-world >/dev/null
declare.pgc:123: WARNING: connection "con2" is overwritten to "con1".
declare.pgc:124: WARNING: connection "con2" is ov
> No, you're right, although I think it's implied. Maybe we need a
> statement along these lines:
>
>
> Committers are responsible for the resolution of open items that
> relate
> to commits they have made. Action needs to be taken in a timely
> fashion,
> and if there is any substantial delay in
> Sure, DECLARE does not matter as it is new. However, please note
> that
> the specific point I was trying to make with my link [2] from
> upthread
> is related to the use of cached connection names with DEALLOCATE, as
> of this line in the new test declare.pgc:
> EXEC SQL DEALLOCATE PREPARE
On Tue, Aug 10, 2021 at 09:31:37AM +0200, Michael Meskes wrote:
>> that it could be a good thing. declare.pgc seems to rely on that
>> already but the tests are incorrect as I mentioned in [2]. For
>> DESCRIBE, that provides data about a result set, I find the
>> assignment
>> of a connection a b
On Tue, Aug 10, 2021 at 1:46 PM Andrew Dunstan wrote:
> No, you're right, although I think it's implied. Maybe we need a
> statement along these lines:
I agree with that, but to me it's more in the scope of what is
expected of committers in general. At a very high level. So it's not
something tha
On 8/10/21 2:16 PM, Michael Meskes wrote:
>> Agreed. How is this, which already exists?
>>
>> https://wiki.postgresql.org/wiki/Release_Management_Team
> That I know, but I don't think it covers the issues we, or I, had up-
> thread. Or do I miss something?
No, you're right, although I
> Agreed. How is this, which already exists?
>
> https://wiki.postgresql.org/wiki/Release_Management_Team
That I know, but I don't think it covers the issues we, or I, had up-
thread. Or do I miss something?
Speaking of RMT, Andrew, Michael, Peter, will you make the final
decision wheth
On Tue, Aug 10, 2021 at 08:05:29PM +0200, Michael Meskes wrote:
> > I think my point was that committers should be required to understand
> > the RMT process, and if we need to communicate that better, let's do
> > that. I don't think it should be the responsibility of RMT members
> > to
> > commu
> I think my point was that committers should be required to understand
> the RMT process, and if we need to communicate that better, let's do
> that. I don't think it should be the responsibility of RMT members
> to
> communicate the RMT process every time they communicate with someone,
> unless
On Tue, Aug 10, 2021 at 09:37:19AM +0200, Michael Meskes wrote:
> > I do think all committers need to understand the role of the RMT so
> > they
> > can respond appropriately. Do we need to communicate this better?
>
> Being the one who assumed a different procedure, yes please. :)
I think my po
Dear Meskes and any hackers,
> Yes, at least technically. I think DESCRIBE should accept the cached
> connection name, although it won't really matter.
I sought docs too and I found that Pro*C have such a same policy,
so it might be reasonable:
https://docs.oracle.com/en/database/oracle/oracle-d
> I do think all committers need to understand the role of the RMT so
> they
> can respond appropriately. Do we need to communicate this better?
Being the one who assumed a different procedure, yes please. :)
Thanks,
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (
> Okay. So you mean to change DESCRIBE and DEALLOCATE to be able to
> handle cached connection names, as of [1]? For [DE]ALLOCATE, I agree
Yes, at least technically. I think DESCRIBE should accept the cached
connection name, although it won't really matter.
> that it could be a good thing. dec
Peter,
> I think that there was a snowballing effect here. We both made
> mistakes that compounded. I apologize for my role in this whole mess.
Completely agreed. I think we both took things for granted that the
other one didn't take into account at all. I'm sorry about that, too.
Michael
--
On Mon, Aug 09, 2021 at 10:50:29PM +0200, Michael Meskes wrote:
>> On the substance of the issue, one question that I have reading over
>> this thread is whether there's really a bug here at all. It is being
>> represented (and I have not checked whether this is accurate) that
>> the
>> patch affec
On Mon, Aug 9, 2021 at 3:51 PM Bruce Momjian wrote:
> > I think that there was a snowballing effect here. We both made
> > mistakes that compounded. I apologize for my role in this whole mess.
>
> I do think all committers need to understand the role of the RMT so they
> can respond appropriately.
On Mon, Aug 9, 2021 at 03:42:45PM -0700, Peter Geoghegan wrote:
> > I'd like to apologize for not answering your email the way I should
> > have. Honestly it never occurred to me. Maybe that's because I'm used
> > to other procedures, or because I never had to converse with the RMT,
> > or maybe,
Michael,
On Mon, Aug 9, 2021 at 3:03 PM Michael Meskes wrote:
> This explains why it felt so difficult to make myself clear. I was
> feeling exactly the same, just the other way round.
My own special brand of miscommunication was also involved. I happen
to be sensitive to the perception that I y
On 8/9/21 6:15 PM, Bruce Momjian wrote:
> On Tue, Aug 10, 2021 at 12:03:24AM +0200, Michael Meskes wrote:
>> I'd like to apologize for not answering your email the way I should
>> have. Honestly it never occurred to me. Maybe that's because I'm used
>> to other procedures, or because I never had
> > Again agreed, please keep in mind, though, that I didn't notice I
> > was
> > being chased until Peter's first email.
>
> I was asked by the RMT to contact one of your employees, and I did,
> to
> tell you that the RMT was looking for feedback from you on an ecpg
> issue. Not sure if that was
On Tue, Aug 10, 2021 at 12:03:24AM +0200, Michael Meskes wrote:
> I'd like to apologize for not answering your email the way I should
> have. Honestly it never occurred to me. Maybe that's because I'm used
> to other procedures, or because I never had to converse with the RMT,
> or maybe, quite sim
On Mon, Aug 9, 2021 at 06:00:00PM -0400, Bruce Momjian wrote:
> > Again agreed, please keep in mind, though, that I didn't notice I was
> > being chased until Peter's first email.
>
> I was asked by the RMT to contact one of your employees, and I did, to
> tell you that the RMT was looking for fe
Peter,
> I think that this must be a cultural thing. I can see how somebody
> would see the third person style as overly formal or stilted. An
> interpretation like that does make sense to me. But I knew of no
> reason why you might find that style made the message offensive. It
> was never intend
On Mon, Aug 9, 2021 at 11:48:07PM +0200, Michael Meskes wrote:
> No, of course not. And sorry for not being precise enough, I only
> objected to the prediction part, but I agree, I take the objection
> back. I guess it's as difficult for Peter to understand why this is
> offensive as it is for me
> > > I don't want to upset anybody for any reason. I regret that my
> > > words
> > > have upset you, but I think that they were misinterpreted in a
> > > way
> > > that I couldn't possibly have predicted. The particular aspect of
> >
> > I strongly object to that. It's pretty obvious to me that
On Mon, Aug 9, 2021 at 1:38 PM Michael Meskes wrote:
> > I don't want to upset anybody for any reason. I regret that my words
> > have upset you, but I think that they were misinterpreted in a way
> > that I couldn't possibly have predicted. The particular aspect of
>
> I strongly object to that.
On Mon, Aug 9, 2021 at 10:38:07PM +0200, Michael Meskes wrote:
> > Clearly we disagree about this. I don't think that there is anything
> > to be gained from discussing this any further, though. I suggest that
> > we leave it at that.
>
> Agreed.
>
> > I don't want to upset anybody for any reaso
On Mon, Aug 9, 2021 at 1:38 PM Michael Meskes wrote:
> > I don't want to upset anybody for any reason. I regret that my words
> > have upset you, but I think that they were misinterpreted in a way
> > that I couldn't possibly have predicted. The particular aspect of
>
> I strongly object to that.
Hi,
> FWIW, I don't think that the phrasing of Peter's email is
> disrespectful. As I read it, it simply states that the RMT has made a
As I said before, it might be a cultural difference. What I don't
understand is, that a simple "Hi Michael, this is what the RMT
decided:" would have been suffic
> question with a question mark. Despite the fact that it is generally
> understood that "committers own their own items", and that the RMT
> exists as a final check on that.
This does not contradict my opinion, but anyway.
> Clearly we disagree about this. I don't think that there is anything
>
On Sat, Aug 7, 2021 at 4:13 AM Michael Meskes wrote:
> I get it that the goal is to release PostgreSQL 14 and I also get it
> that nobody is interested in the reasons for my slow reaction. I even,
> at least to an extend, understand why nobody tried reaching out to me
> directly. However, what I c
On Mon, Aug 9, 2021 at 11:45 AM Michael Meskes wrote:
> If you want me to answer, how about asking a question? Or telling me
> that you'd like some feedback? I don't see how I should know that you
> expect a reply to a simple statement of facts.
I expressed concern in fairly strong terms, and rec
> My email of July 30 was itself pretty strongly worded, but went
> unanswered for a full week. Not even a token response. If that
> doesn't
> count as "ignoring the RMT", then what does? How much time has to
> pass
> before radio silence begins to count as "ignoring the RMT", in your
> view of thi
On Mon, Aug 9, 2021 at 12:10 AM Michael Meskes wrote:
> How do you know I didn't spend 15 minutes looking at the patch and the
> whole email thread? I surely did and it was more than 15 minutes, but
> not enough to give a meaningful comment. If you can do it in 15
> minutes, great for you, I canno
Dear Kuroda-san,
> I perfectly missed mails and 8/9 was a national holiday.
> I must apologize about anything. Very sorry for inconvenience.
No need to, non of it is your fault.
> I summarize the thread.
Thank you so much, this is very, very helpful.
> As you might know DECLARE STATEMENT has
Dear Horiguchi-san,
> How Pro*C behaves in that case? If the second command ends with an
> error, I think we are free to error out the second command before
> execution. If it works... do you know what is happening at the time?
You asked that how Oracle works when the followings precompiled and
e
Dear Wang,
Good reporting!
> I'm not sure, but how about modify the ecpg.trailer:
> > statement: ecpgstart at toplevel_stmt ';' { connection = NULL; }
> > | ecpgstart toplevel_stmt ';'
> I think there are lots of 'connection = NULL;' in source, and we should find a
good location to reset the conn
Dear Hackers,
I perfectly missed mails and 8/9 was a national holiday.
I must apologize about anything. Very sorry for inconvenience.
> The RMT's first responsibility is to ensure that PostgreSQL 14 is
> released on schedule. We would prefer to avoid a revert, but we cannot
> allow this to drag o
> I think that it's crystal clear what I meant in the email of July 30.
> I meant: it's not okay that you're simply ignoring the RMT. You
> hadn't
> even made a token effort at that point. For example you didn't give
> the proposed fix a cursory 15 minute review, just so we had some very
> rough id
On Sun, Aug 8, 2021 at 11:34 AM Michael Meskes wrote:
> > https://postgr.es/m/CAH2-Wzk=qxtsp0h5ekv92eh0u22hvmqlhgwyp4_fa3ytiei...@mail.gmail.com
>
> This email said nothing about sending a status update or a deadline or
> any question at all, only that you'd revert the patch if I was unable
> to r
On Sat, 2021-08-07 at 15:31 -0700, Peter Geoghegan wrote:
> On Sat, Aug 7, 2021 at 12:43 PM Michael Meskes
> wrote:
> > Again, I didn't know the RMT was expecting anything from me. Yes, I
> > knew I needed to spend some time on a technical issues, but that's
> > exactly the information I had at th
On Sat, Aug 7, 2021 at 12:43 PM Michael Meskes wrote:
> Again, I didn't know the RMT was expecting anything from me. Yes, I
> knew I needed to spend some time on a technical issues, but that's
> exactly the information I had at the time.
As Andrew mentioned, I sent you an email on the 30th -- a f
On 8/7/21 3:43 PM, Michael Meskes wrote:
>
>> No other committer (certainly nobody on the RMT) knows anything about
>> ecpg. How much longer were you expecting us to wait for a simple
>> status update?
> Where did I say I expect you to wait? How could I even do that given
> that I didn't even kno
> That's simply not true. Andrew Dunstan reached out personally and got
> no response. He then reached out through a backchannel (a direct
> coworker of yours), before finally getting a single terse response
> from you here.
You do know that I did not receive any email from Andrew. After all I
exp
On Sat, Aug 7, 2021 at 1:13 AM Michael Meskes wrote:
> I get it that the goal is to release PostgreSQL 14 and I also get it
> that nobody is interested in the reasons for my slow reaction. I even,
> at least to an extend, understand why nobody tried reaching out to me
> directly.
That's simply no
Hi Peter,
> The RMT continues to be concerned about the lack of progress on this
> open item, especially the lack of communication from Michael Meskes,
> the committer of the original patch (commit ad8305a). We are prepared
> to exercise our authority to resolve open items directly. The only
> fal
On Fri, Jul 30, 2021 at 3:01 PM Peter Geoghegan wrote:
> The RMT discussed this recently. We are concerned about this issue,
> including how it has been handled so far.
>
> If you're unable to resolve the issue (or at least commit time to
> resolving the issue) then the RMT will call for the rever
On Thu, Jul 29, 2021 at 12:22 PM Michael Meskes wrote:
> I just wanted to let you know that I'm well aware of this thread but
> need to get through my backlog before I can comment. Sorry for the
> delay.
The RMT discussed this recently. We are concerned about this issue,
including how it has been
All,
> between DECLARE and the past queries qualify as an open item. I am
> adding Michael Meskes in CC. I got to wonder how much of a
> compatibility break it would be for DEALLOCATE and DESCRIBE to handle
> EXEC SQL AT in a way more consistent than DECLARE, even if these are
> bounded to a re
Hello, Kuroda-san.
At Mon, 12 Jul 2021 04:05:21 +, "kuroda.hay...@fujitsu.com"
wrote in
> > 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 cas
---Original Message-
From: kuroda.hay...@fujitsu.com
Sent: Monday, July 12, 2021 12:05 PM
To: 'Kyotaro Horiguchi'
Cc: pgsql-hackers@lists.postgresql.org
Subject: RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Dear Horiguchi-san,
Thank you for reviewing! I attac
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-
On Thu, Jul 08, 2021 at 11:42:14AM +, kuroda.hay...@fujitsu.com wrote:
> I already said above, I think that DEALLOCATE statement should
> follow the linked connection, but I cannot decide about DESCRIBE.
> I want to ask how do you think.
I am not completely sure. It would be good to hear from
Dear Michael,
> I have been chewing on this comment and it took me some time to
> understand what you meant here.
Sorry... But your understanding is correct.
> It is true that the ecpglib part, aka
> all the routines you are quoting above, don't rely at all on the
> connection names. However, t
At Fri, 2 Jul 2021 12:53:02 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Hackers,
>
> I revised my patch.
Thanks for the new version.
> > However, I perfectly agree that it's very difficult for users to find a
> > problem from the message.
> > I will try to add information to it in the
On Tue, Jul 06, 2021 at 04:58:03PM +0900, Michael Paquier wrote:
> I have been chewing on this comment and it took me some time to
> understand what you meant here. It is true that the ecpglib part, aka
> all the routines you are quoting above, don't rely at all on the
> connection names. However
On Fri, Jul 02, 2021 at 12:53:02PM +, kuroda.hay...@fujitsu.com wrote:
> I added such a message and some tests, but I began to think this is strange.
> Now I'm wondering why the connection is checked in some DESCRIPTOR-related
> statements? In my understanding connection name is not used in
>
Dear Hackers,
I revised my patch.
> Please also ensure that you're generating the patch against git HEAD.
> The cfbot shows it as failing to apply, likely because you're looking
> at something predating ad8305a43d1890768a613d3fb586b44f17360f29.
Maybe there was something wrong with my local envir
"kuroda.hay...@fujitsu.com" writes:
>> The test portion bloats the patch so it would be easier to read if
>> that part is separated from the code part.
> Right, I'll separate and attach again few days. Sorry for inconvenience;-(.
Please also ensure that you're generating the patch against git HE
Dear Horiguchi-san,
Thank you for replying!
> (Maybe by consulting the code.. Anyway, )
I noticed the patch cannot be applied...
> The follwoing commands don't.
> DESCRIBE
> DEALLOCATE
> DECLARE CURSOR .. FOR
> CREATE TABLE AS EXECUTE
I'm not sure about `CREATE TABLE AS EXECUTE`(I'll check you
At Thu, 01 Jul 2021 17:48:49 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 25 Jun 2021 12:02:22 +, "kuroda.hay...@fujitsu.com"
> wrote in
> The following commands handle the liked connection.
> DECLARE
> PREPARE
> EXECUTE
>
> The follwoing commands don't.
> DESCRIBE
> DEALLOCATE
> DE
At Fri, 25 Jun 2021 12:02:22 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Hackers,
>
> I checked about DECLARE STATEMENT(added from ad8305a), and I noticed that
> this connection-control feature cannot be used for DEALLOCATE and DESCRIBE
> statement.
>
> I attached the patch that fixes
70 matches
Mail list logo
