On Tue, Feb 25, 2025 at 02:42:17PM +0300, Ilia Evdokimov wrote:
> I´ve addressed all your comments on the v9 patch for updating the
> descriptions of auto_explain.log_min_duration and
> auto_explain.log_parameter_max_length. Just wanted to check if you had a
> chance to take another look. Let me kn
On 18.02.2025 01:13, Ilia Evdokimov wrote:
Thank you for reviewing! I agree with all of them. I updated patch v9
with these changes.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
Hi hackers,
I’ve addressed all your comments on the v9 patch for updating the
descriptions of auto_expl
On 18.02.2025 00:55, Nathan Bossart wrote:
On Tue, Feb 18, 2025 at 08:14:58AM +1100, Peter Smith wrote:
SUGGESTION
"-1 disables logging plans. 0 means log all plans."
+1
DefineCustomIntVariable("auto_explain.log_parameter_max_length",
"Sets the maximum length of query parameters to log
On Tue, Feb 18, 2025 at 08:14:58AM +1100, Peter Smith wrote:
> SUGGESTION
> "-1 disables logging plans. 0 means log all plans."
+1
> DefineCustomIntVariable("auto_explain.log_parameter_max_length",
> "Sets the maximum length of query parameters to log.",
> - "Zero logs no query parameters, -1
On Mon, Feb 17, 2025 at 8:50 PM Ilia Evdokimov
wrote:
>
>
> On 14.02.2025 19:47, Nathan Bossart wrote:
> > On Thu, Feb 13, 2025 at 05:01:59PM -0600, Nathan Bossart wrote:
> >> Okay, I took your suggestions in v7.
> > Committed. Thanks, David, Peter, and Daniel!
> >
>
> Hi,
>
> Maybe I'm being pic
On 14.02.2025 19:47, Nathan Bossart wrote:
On Thu, Feb 13, 2025 at 05:01:59PM -0600, Nathan Bossart wrote:
Okay, I took your suggestions in v7.
Committed. Thanks, David, Peter, and Daniel!
Hi,
Maybe I'm being picky, but in auto_explain, the parameters
log_min_duration and log_parameter_m
On Thu, Feb 13, 2025 at 05:01:59PM -0600, Nathan Bossart wrote:
> Okay, I took your suggestions in v7.
Committed. Thanks, David, Peter, and Daniel!
--
nathan
7.
--
nathan
>From 7526dcc25c992be8e2bc6aed2a030dcdd1d536e2 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 12 Feb 2025 14:26:00 -0600
Subject: [PATCH v7 1/1] Describe special values in GUC descriptions more
consistently.
Many GUCs accept special values like -1 or an empty string to
di
On Thu, Feb 13, 2025 at 3:18 PM Nathan Bossart
wrote:
> On Wed, Feb 12, 2025 at 04:10:53PM -0700, David G. Johnston wrote:
> > I presume it doesn't affect the actual output which just concatenates the
> > fragments together but the source placement probably should be made
> > consistent; the line
4:26:00 -0600
Subject: [PATCH v6 1/1] Describe special values in GUC descriptions more
consistently.
Many GUCs accept special values like -1 or an empty string to
disable the feature, use a system default, etc. While the
documentation consistently lists these special values, the GUC
descriptions
On Wed, Feb 12, 2025 at 3:47 PM Nathan Bossart
wrote:
> Good catch. I've fixed that in v5.
>
>
I presume it doesn't affect the actual output which just concatenates the
fragments together but the source placement probably should be made
consistent; the line containing the initial default value s
cuum actions. 0 means log
> all autovacuum actions."),
Good catch. I've fixed that in v5.
--
nathan
>From f5e757046c40bfa118c10cae82edc55dc7679dca Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 12 Feb 2025 14:26:00 -0600
Subject: [PATCH v5 1/1] Describe special valu
One last thing...
- gettext_noop("Zero logs all files. The default is -1 (turning this
feature off)."),
+ gettext_noop("-1 disables temporary file logs. 0 means log all
temporary files."),
The first sentence could be ambiguous. E.g. "temporary file logs"
might be interpreted as meaning logs about
> On 12 Feb 2025, at 22:04, Nathan Bossart wrote:
>
> Here is what I have staged for commit, which I intend to do within the next
> couple of days unless there is additional feedback. In v4, I've added a
> commit message, removed the changes to the ssl_crl_* parameters, and fixed
> a couple of v
>From 3205f1172ac6ec2a82171bba554bca17bb8702cb Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 12 Feb 2025 14:26:00 -0600
Subject: [PATCH v4 1/1] Describe special values in GUC descriptions more
consistently.
Many GUCs accept special values like -1 or an empty string to
disable the feature, use a system defa
On Tue, Feb 11, 2025 at 11:41:51PM +0100, Daniel Gustafsson wrote:
>> On 11 Feb 2025, at 19:11, Nathan Bossart wrote:
>
>> I thought about this one a bit, and I actually came to the opposite
>> conclusion. IMHO it's reasonably obvious that an empty string means that
>> the file isn't loaded, so
> On 11 Feb 2025, at 19:11, Nathan Bossart wrote:
> I thought about this one a bit, and I actually came to the opposite
> conclusion. IMHO it's reasonably obvious that an empty string means that
> the file isn't loaded, so there's not much point in stating it in the GUC
> description. Instead,
I don't have an opinion about the ssl_crl stuff. Everything else looks
good to me.
==
Kind Regards,
Peter Smith.
Fujitsu Australia.
c of
> these two choices seems awkward.
I thought about this one a bit, and I actually came to the opposite
conclusion. IMHO it's reasonably obvious that an empty string means that
the file isn't loaded, so there's not much point in stating it in the GUC
descr
On Mon, Feb 10, 2025 at 4:53 PM Peter Smith wrote:
> On Tue, Feb 11, 2025 at 9:25 AM Nathan Bossart
> wrote:
> >
> > On Tue, Feb 11, 2025 at 08:29:28AM +1100, Peter Smith wrote:
> > > +1 for this. Your wording examples below look good to me..
> >
> > Okay, how does this look?
> >
> > --
>
> v2 m
On Tue, Feb 11, 2025 at 9:25 AM Nathan Bossart wrote:
>
> On Tue, Feb 11, 2025 at 08:29:28AM +1100, Peter Smith wrote:
> > +1 for this. Your wording examples below look good to me..
>
> Okay, how does this look?
>
> --
v2 mostly looked good to me. Just a couple of questions.
~~~
1.
{"shared_m
-0600
Subject: [PATCH v2 1/1] Describe special values in GUC descriptions more
consistently.
---
src/backend/utils/misc/guc_tables.c | 139 ++--
1 file changed, 70 insertions(+), 69 deletions(-)
diff --git a/src/backend/utils/misc/guc_tables.c
b/src/backend/utils/misc/guc_ta
On Tue, Feb 11, 2025 at 3:22 AM David G. Johnston
wrote:
>
> On Mon, Feb 10, 2025 at 9:02 AM Nathan Bossart
> wrote:
>>
>> On Mon, Feb 10, 2025 at 09:13:26AM +1100, Peter Smith wrote:
>> > +1 for improving consistency.
>>
>> Thanks for reviewing.
>>
>> > 1. IMO all places wording as "XXX means t
On Mon, Feb 10, 2025 at 9:02 AM Nathan Bossart
wrote:
> On Mon, Feb 10, 2025 at 09:13:26AM +1100, Peter Smith wrote:
> > +1 for improving consistency.
>
> Thanks for reviewing.
>
> > 1. IMO all places wording as "XXX means to YYY" should be just "XXX
> > means YYY" (e.g. remove the "to")
> >
> >
On Mon, Feb 10, 2025 at 09:13:26AM +1100, Peter Smith wrote:
> +1 for improving consistency.
Thanks for reviewing.
> 1. IMO all places wording as "XXX means to YYY" should be just "XXX
> means YYY" (e.g. remove the "to")
>
> e.g. "-1 means to wait forever." => "-1 means wait forever."
> e.g. ""-
On Sat, Feb 8, 2025 at 9:27 AM Nathan Bossart wrote:
>
> For many GUCs, special values like -1, "", etc. have some sort of special
> meaning, such as disabling the feature. While the documentation seems to
> be reasonably good about listing special values, the GUC descriptions are
> less consiste
n Bossart
Date: Fri, 7 Feb 2025 16:06:18 -0600
Subject: [PATCH v1 1/1] Describe special values in GUC descriptions more
consistently.
---
src/backend/utils/misc/guc_tables.c | 139 ++--
1 file changed, 70 insertions(+), 69 deletions(-)
diff --git a/src/backend/
On Tue, Aug 16, 2022 at 9:04 PM Bruce Momjian wrote:
>
> On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote:
> > I have updated the patch to display "Objects depending on extension"
> > as describe extension footer. The changes for the same are available
On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote:
> I have updated the patch to display "Objects depending on extension"
> as describe extension footer. The changes for the same are available
> in the v2 version patch attached. Thoughts?
I wonder if we would b
On Sun, Aug 14, 2022 at 10:24 PM vignesh C wrote:
>
> On Sun, Aug 14, 2022 at 11:07 AM Tom Lane wrote:
> >
> > vignesh C writes:
> > > Currently we do not include the dependent extension information for
> > > index and materialized view in the describe comm
On Sun, Aug 14, 2022 at 11:07 AM Tom Lane wrote:
>
> vignesh C writes:
> > Currently we do not include the dependent extension information for
> > index and materialized view in the describe command. I felt it would
> > be useful to include this information as part
vignesh C writes:
> Currently we do not include the dependent extension information for
> index and materialized view in the describe command. I felt it would
> be useful to include this information as part of the describe command
> like:
> \d+ idx_depends
>
Hi,
Currently we do not include the dependent extension information for
index and materialized view in the describe command. I felt it would
be useful to include this information as part of the describe command
like:
\d+ idx_depends
Index "public.idx_depends"
Colu
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
>> assignm
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/or
> 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 b
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
--
e) that
>> the
>> patch affects the behavior of DECLARE, PREPARE, and EXECUTE, but not
>> DESCRIBE, DEALLOCATE, DECLARE CURSOR .. FOR, or CREATE TABLE AS
>> EXECUTE. However, it also seems that it's not entirely clear what the
>> behavior ought to be in those cases,
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.
ead 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 affects the behavior of DECLARE, PREPARE, and EXECUTE, but not
> DESCRIBE, DEALLOCATE, DECLARE CURSOR .. FOR, or CREATE TABLE AS
>
> 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
>
n 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 affects the behavior of DECLARE, PREPARE, and EXECUTE, but not
DESCRIBE, DEALLOCATE, DECLARE CURSOR .. FOR, or CREATE TAB
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
RE STATEMENT has been added from PG14, but I
> found that connection-control feature cannot be used for DEALLOCATE
> and DESCRIBE statement (More details, please see patches or ask me).
> But we have a question - what statement should use the associated
> connection? Obviously DEALLOCATE
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
w this to drag on indefinitely.
Of cause I will try to avoid it but I can understand doing your business.
Dear Meskes,
I summarize the thread.
As you might know DECLARE STATEMENT has been added from PG14, but I
found that connection-control feature cannot be used for DEALLOCATE
and DESCRIBE s
> 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
&g
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 goo
ng to need more time to finish evaluating this patch, but it
> seems that this moves to the right direction. The new warnings for
> lookup_descriptor() and drop_descriptor() with the connection name are
> useful. Should we have more cases with con2 in the new set of tests
> for DESCRI
some of the names are spelled wrongly until
runtime. If it were a string we can live without the check but it is
seemingly an identifier so it is strange that it is not detected at
compile-time. I guess that it is the motivation for the check.
What makes the story complex is that connection matte
the way, as DECLARE is new as of v14, I think that the interactions
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 con
me to finish evaluating this patch, but it
seems that this moves to the right direction. The new warnings for
lookup_descriptor() and drop_descriptor() with the connection name are
useful. Should we have more cases with con2 in the new set of tests
for DESCRIBE?
--
Michael
signature.asc
Description: PGP signature
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
1 - 100 of 174 matches
Mail list logo
