Hi,
On 2022-04-06 10:37:29 +0200, Peter Eisentraut wrote:
> On 06.04.22 04:06, Andres Freund wrote:
> > On 2022-04-04 23:32:50 +0200, Peter Eisentraut wrote:
> > > This has been committed.
> >
> > It's somewhat annoying that made pg_regress even more verbose than before:
> >
> > == r
On 06.04.22 04:06, Andres Freund wrote:
On 2022-04-04 23:32:50 +0200, Peter Eisentraut wrote:
This has been committed.
It's somewhat annoying that made pg_regress even more verbose than before:
== removing existing temp instance==
== creating tempor
Hi,
On 2022-04-04 23:32:50 +0200, Peter Eisentraut wrote:
> This has been committed.
It's somewhat annoying that made pg_regress even more verbose than before:
== removing existing temp instance==
== creating temporary instance=
On 02.04.22 15:26, Fabien COELHO wrote:
Again, after the SendQuery refactoring extraction.
I'm doing this locally, so don't feel obliged to send more of these. ;-)
Good for me :-)
This has been committed.
I reduced some of your stylistic changes in order to keep the surface
area of this
Again, after the SendQuery refactoring extraction.
I'm doing this locally, so don't feel obliged to send more of these. ;-)
Good for me :-)
--
Fabien.
On 01.04.22 07:46, Fabien COELHO wrote:
Attached a rebase.
Again, after the SendQuery refactoring extraction.
I'm doing this locally, so don't feel obliged to send more of these. ;-)
I've started committing this now, in pieces.
Attached a rebase.
Again, after the SendQuery refactoring extraction.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/contrib/pg_stat_statements/expected/pg_stat_statements.out
index e0abe34bb6..8f7f93172a 100644
--- a/contrib/pg_stat_statements/expected/pg
Attached a rebase.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/contrib/pg_stat_statements/expected/pg_stat_statements.out
index e0abe34bb6..8f7f93172a 100644
--- a/contrib/pg_stat_statements/expected/pg_stat_statements.out
+++ b/contrib/pg_stat_statements/
Hello Peter,
As Tom said earlier, wasn't this fixed by 618c16707? If not, is there any
other discussion on the specifics of this issue? I'm not aware of one.
This answer is that I had kept psql's calls to PQerrorMessage which
reports errors from the connection, whereas it needed to change
As Tom said earlier, wasn't this fixed by 618c16707? If not, is there any
other discussion on the specifics of this issue? I'm not aware of one.
Hmmm… I'll try to understand why the doubled message seems to be still
there.
--
Fabien.
On 23.03.22 13:58, Fabien COELHO wrote:
If you want to wait for libpq to provide a solution for this corner
case, I'm afraid that "never" is the likely result, especially as no
test case exercices this path to show that there is a problem somewhere,
so nobody should care to fix it. I'm not sure
Hello Peter,
Attached v17 is another try. The point is to record the current status,
whatever it is, buggy or not, and to update the test when libpq fixes
things, whenever this is done.
[...]
The expected output (which passes) contains this line twice:
psql::2: FATAL: terminating connect
On 17.03.22 19:04, Fabien COELHO wrote:
Indeed! The missing part was put back in v17.
Some unrelated notes on this v17 patch:
-use Test::More;
+use Test::More tests => 41;
The test counts are not needed/wanted anymore.
+
+\set ECHO none
+
This seems inappropriate.
+--
+-- autocommit
+--
On 17.03.22 19:04, Fabien COELHO wrote:
Hello Peter,
See attached v16 which removes the libpq workaround.
I suppose this depends on
https://www.postgresql.org/message-id/flat/ab4288f8-be5c-57fb-2400-e3e857f53e46%40enterprisedb.com
getting committed, because right now this makes the psql
Hello Peter,
See attached v16 which removes the libpq workaround.
I suppose this depends on
https://www.postgresql.org/message-id/flat/ab4288f8-be5c-57fb-2400-e3e857f53e46%40enterprisedb.com
getting committed, because right now this makes the psql TAP tests fail
because of the duplicate er
Peter Eisentraut writes:
> I suppose this depends on
> https://www.postgresql.org/message-id/flat/ab4288f8-be5c-57fb-2400-e3e857f53e46%40enterprisedb.com
> getting committed, because right now this makes the psql TAP tests fail
> because of the duplicate error message.
Umm ... wasn't 618c16707 w
On 12.03.22 17:27, Fabien COELHO wrote:
Are you planning to send a rebased patch for this commit fest?
Argh, I did it in a reply in another thread:-( Attached v15.
So as to help moves things forward, I'd suggest that we should not to
care too much about corner case repetition of some error
Are you planning to send a rebased patch for this commit fest?
Argh, I did it in a reply in another thread:-( Attached v15.
So as to help moves things forward, I'd suggest that we should not to care
too much about corner case repetition of some error messages which are due to
libpq internal
Are you planning to send a rebased patch for this commit fest?
Argh, I did it in a reply in another thread:-( Attached v15.
So as to help moves things forward, I'd suggest that we should not to care
too much about corner case repetition of some error messages which are due
to libpq interna
On 15.01.22 10:00, Fabien COELHO wrote:
The reason this test constantly fails on cfbot windows is a
use-after-free
bug.
Indeed! Thanks a lot for the catch and the debug!
The ClearOrSaveResult function is quite annoying because it may or may
not clear the result as a side effect.
Attached v
I wrote a few more small tests for psql to address uncovered territory
in SendQuery() especially:
- \timing
- client encoding handling
- notifications
What's still missing is:
- \watch
- pagers
For \watch, I think one would need something like the current cancel
test (since you need to get t
On 29.01.22 15:40, Fabien COELHO wrote:
With this approach results are not available till the last one has been
returned? If so, it loses the nice asynchronous property of getting
results as they come when they come? This might or might not be
desirable depending on the use case. For "psql", IS
Hello Peter,
It would be better to do without. Also, it makes one wonder how others
are supposed to use this multiple-results API properly, if even psql can't
do it without extending libpq. Needs more thought.
Fine with me! Obviously I'm okay if libpq is repaired instead of writing
strange
On 23.01.22 18:17, Fabien COELHO wrote:
But I think if we are adding a libpq API function to work around a
misbehavior in libpq, we might as well fix the misbehavior in libpq to
begin with. Adding a new public libpq function is a significant step,
needs documentation, etc.
I'm not so sure.
Hallo Peter,
Attached v14 moves the status extraction before the possible clear. I've
added a couple of results = NULL after such calls in the code.
In the psql.sql test file, the test I previously added concluded with \set
ECHO none, which was a mistake that I have now fixed. As a result,
On 15.01.22 10:00, Fabien COELHO wrote:
The reason this test constantly fails on cfbot windows is a
use-after-free
bug.
Indeed! Thanks a lot for the catch and the debug!
The ClearOrSaveResult function is quite annoying because it may or may
not clear the result as a side effect.
Attached v
Hello Andres,
The reason this test constantly fails on cfbot windows is a use-after-free
bug.
Indeed! Thanks a lot for the catch and the debug!
The ClearOrSaveResult function is quite annoying because it may or may not
clear the result as a side effect.
Attached v14 moves the status extra
Hi,
On 2022-01-08 19:32:36 +0100, Fabien COELHO wrote:
> Attached v13 where the crash test is moved to tap.
The reason this test constantly fails on cfbot windows is a use-after-free
bug.
I figured that out in the context of another thread, so the debugging is
there:
https://postgr.es/m/2022011
Hello Peter,
quite weird and confusing. Maybe this type of test should be done in
the TAP framework instead.
Attached v13 where the crash test is moved to tap.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/contrib/pg_stat_statements/expected/pg_stat_sta
Hello Peter,
With this "voluntary crash", the regression test output is now
psql ... ok (test process exited with exit
code 2) 281 ms
Normally, I'd expect this during development if there was a crash somewhere,
but showing this during a normal run now,
On 23.12.21 12:40, Fabien COELHO wrote:
This is also a feature/bug of libpq which happens to be hidden by
PQexec: when one command crashes PQgetResult actually returns *2*
results. First one with the FATAL message, second one when libpq figures
out that the connection was lost with the second m
[...]
I agree that these two behaviors in libpq are dubious, especially the
second one. I want to spend some time analyzing this more and see if
fixes in libpq might be appropriate.
Ok.
My analysis is that fixing libpq behavior is not in the scope of a psql
patch, and that if I was to
On 23.12.21 12:40, Fabien COELHO wrote:
In [0], it was reported that certain replication commands result in
infinite loops because of faulty error handling. This still happens.
I wrote a test for it, attached here. (I threw in a few more basic
tests, just to have some more coverage that was
Hello Peter,
I finally took some time to look at this.
Attached v11 is a rebase.
This patch still has a few of the problems reported earlier this year.
In [0], it was reported that certain replication commands result in infinite
loops because of faulty error handling. This still happens.
Hello Daniel,
This patch still has a few of the problems reported earlier this year.
The patch fails to apply and the thread seems to have taken a nap.
I'm not napping:-) I just do not have enough time available this month. I
intend to work on the patch in the next CF (January). AFAICR th
> On 8 Oct 2021, at 14:15, Peter Eisentraut
> wrote:
>
> On 02.10.21 16:31, Fabien COELHO wrote:
>>> Attached v9 integrates your tests and makes them work.
>> Attached v11 is a rebase.
>
> This patch still has a few of the problems reported earlier this year.
The patch fails to apply and the t
On 02.10.21 16:31, Fabien COELHO wrote:
Attached v9 integrates your tests and makes them work.
Attached v11 is a rebase.
This patch still has a few of the problems reported earlier this year.
In [0], it was reported that certain replication commands result in
infinite loops because of fault
Hello Peter,
Attached v9 integrates your tests and makes them work.
Attached v11 is a rebase.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/contrib/pg_stat_statements/expected/pg_stat_statements.out
index b52d187722..0cf4a37a5f 100644
--- a/contrib/pg_st
Hallo Peter,
It turns out that your v8 patch still has the issue complained about in [0].
The issue is that after COMMIT AND CHAIN, the internal savepoint is gone, but
the patched psql still thinks it should be there and tries to release it,
which leads to errors.
Indeed. Thanks for the cat
On 22.07.21 16:58, Fabien COELHO wrote:
Ok. I noticed. The patch got significantly broken by the watch pager
commit. I also have to enhance the added tests (per Peter request).
I wrote a test to check psql query cancel support. I checked that it
fails against the patch that was reverted. May
On 22.07.21 16:58, Fabien COELHO wrote:
Here is the updated version (v8? I'm not sure what the right count is),
which works for me and for "make check", including some tests added for
uncovered paths.
I included your tap test (thanks again!) with some more comments and
cleanup.
The tap test
pá 23. 7. 2021 v 9:41 odesílatel Fabien COELHO napsal:
>
> >>> I tested manually for the pager feature, which mostly work, althoug
> >>> "pspg --stream" does not seem to expect two tables, or maybe there is
> >>> a way to switch between these that I have not found.
> >>
> >> pspg doesn't support
I tested manually for the pager feature, which mostly work, althoug
"pspg --stream" does not seem to expect two tables, or maybe there is
a way to switch between these that I have not found.
pspg doesn't support this feature.
Sure. Note that it is not a feature yet:-)
ISTM that having som
čt 22. 7. 2021 v 17:23 odesílatel Pavel Stehule
napsal:
>
>
> čt 22. 7. 2021 v 16:58 odesílatel Fabien COELHO
> napsal:
>
>>
>> >> Ok. I noticed. The patch got significantly broken by the watch pager
>> >> commit. I also have to enhance the added tests (per Peter request).
>> >
>> > I wrote a te
čt 22. 7. 2021 v 16:58 odesílatel Fabien COELHO
napsal:
>
> >> Ok. I noticed. The patch got significantly broken by the watch pager
> >> commit. I also have to enhance the added tests (per Peter request).
> >
> > I wrote a test to check psql query cancel support. I checked that it
> fails
> > ag
čt 22. 7. 2021 v 16:49 odesílatel Fabien COELHO
napsal:
>
> Hello,
>
> > Minimally for PSQL_WATCH_PAGER, the pager should exit after some time,
> but
> > before it has to repeat data reading. Elsewhere the psql will hang.
>
> Sure. The "pager.pl" script I sent exits after reading a few lines.
>
>
Ok. I noticed. The patch got significantly broken by the watch pager
commit. I also have to enhance the added tests (per Peter request).
I wrote a test to check psql query cancel support. I checked that it fails
against the patch that was reverted. Maybe this is useful.
Here is the update
Hello,
Minimally for PSQL_WATCH_PAGER, the pager should exit after some time, but
before it has to repeat data reading. Elsewhere the psql will hang.
Sure. The "pager.pl" script I sent exits after reading a few lines.
can be solution to use special mode for psql, when psql will do write to
čt 22. 7. 2021 v 11:00 odesílatel Fabien COELHO
napsal:
>
> Hello Pavel,
>
> >> The newly added PSQL_WATCH_PAGER feature which broke the patch does not
> >> seem to be tested anywhere, this is tiring:-(
> >
> > Do you have any idea how this can be tested?
>
> The TAP patch sent by Peter on this t
Hello Pavel,
The newly added PSQL_WATCH_PAGER feature which broke the patch does not
seem to be tested anywhere, this is tiring:-(
Do you have any idea how this can be tested?
The TAP patch sent by Peter on this thread is a very good start.
It requires some pager that doesn't use blocking
Hi
čt 22. 7. 2021 v 7:52 odesílatel Fabien COELHO napsal:
>
> >>> The patch does not apply on Head anymore, could you rebase and post a
> >>> patch. I'm changing the status to "Waiting for Author".
> >>
> >> Ok. I noticed. The patch got significantly broken by the watch pager
> >> commit. I also
The patch does not apply on Head anymore, could you rebase and post a
patch. I'm changing the status to "Waiting for Author".
Ok. I noticed. The patch got significantly broken by the watch pager
commit. I also have to enhance the added tests (per Peter request).
I wrote a test to check psql
On 15.07.21 17:46, Fabien COELHO wrote:
The patch does not apply on Head anymore, could you rebase and post a
patch. I'm changing the status to "Waiting for Author".
Ok. I noticed. The patch got significantly broken by the watch pager
commit. I also have to enhance the added tests (per Peter r
The patch does not apply on Head anymore, could you rebase and post a
patch. I'm changing the status to "Waiting for Author".
Ok. I noticed. The patch got significantly broken by the watch pager
commit. I also have to enhance the added tests (per Peter request).
--
Fabien.
On Sat, Jun 12, 2021 at 3:11 PM Fabien COELHO wrote:
>
>
> Hello Peter,
>
> >> My overly naive trust in non regression test to catch any issues has been
> >> largely proven wrong. Three key features do not have a single tests. Sigh.
> >>
> >> I'll have some time to look at it over next week-end, b
On 12.06.21 11:41, Fabien COELHO wrote:
The patch includes basic AUTOCOMMIT and ON_ERROR_ROLLBACK tests, which
did not exist before, at all.
I looked at these tests first. The tests are good, they increase
coverage. But they don't actually test the issue that was broken by the
previous patc
Hello Peter,
My overly naive trust in non regression test to catch any issues has been
largely proven wrong. Three key features do not have a single tests. Sigh.
I'll have some time to look at it over next week-end, but not before.
I have reverted the patch and moved the commit fest entry t
On 15.04.21 13:51, Fabien COELHO wrote:
That's a lot IMO, so my vote would be to discard this feature for now
and revisit it properly in the 15 dev cycle, so as resources are
redirected into more urgent issues (13 open items as of the moment of
writing this email).
I don't wish to tell people w
Hello Tom,
That's a lot IMO, so my vote would be to discard this feature for now
and revisit it properly in the 15 dev cycle, so as resources are
redirected into more urgent issues (13 open items as of the moment of
writing this email).
I don't wish to tell people which open issues they ough
Michael Paquier writes:
> On Mon, Apr 12, 2021 at 03:33:01PM -0400, Alvaro Herrera wrote:
>> I, for one, would prefer to see the feature repaired in this cycle.
> If it is possible to get that fixed, I would not mind waiting a bit
> more but it would be nice to see some actual proposals. There a
On Mon, Apr 12, 2021 at 03:33:01PM -0400, Alvaro Herrera wrote:
> Please note that there's no "for now" about it -- if the patch is
> reverted, the only way to get it back is to wait for PG15. That's
> undesirable. A better approach is to collect all those bugs and get
> them fixed. There's plen
On Mon, Apr 12, 2021 at 07:08:21PM +, Bossart, Nathan wrote:
> I think I've found another issue with this patch. If AcceptResult()
> returns false in SendQueryAndProcessResults(), it seems to result in
> an infinite loop of "unexpected PQresultStatus" messages. This can be
> reproduced by try
On 2021-Apr-12, Bossart, Nathan wrote:
> The following patch seems to resolve the issue, although I'll admit I
> haven't dug into this too deeply. In any case, +1 for reverting the
> patch for now.
Please note that there's no "for now" about it -- if the patch is
reverted, the only way to get it
On 4/12/21, 9:25 AM, "Tom Lane" wrote:
> Fabien COELHO writes:
>>> Between this and the known breakage of control-C, it seems clear
>>> to me that this patch was nowhere near ready for prime time.
>>> I think shoving it in on the last day before feature freeze was
>>> ill-advised, and it ought to
Fabien COELHO writes:
>> Between this and the known breakage of control-C, it seems clear
>> to me that this patch was nowhere near ready for prime time.
>> I think shoving it in on the last day before feature freeze was
>> ill-advised, and it ought to be reverted. We can try again later.
> The
Hello Tom,
It's right: this is dead code because all paths through the if-nest
starting at line 1373 now leave results = NULL. Hence, this patch
has broken the autocommit logic;
Do you mean yet another feature without a single non-regression test? :-(
I tend to rely on non regression tests
On Sun, Apr 11, 2021 at 11:14:07AM -0400, Tom Lane wrote:
> It's right: this is dead code because all paths through the if-nest
> starting at line 1373 now leave results = NULL. Hence, this patch
> has broken the autocommit logic; it's no longer possible to tell
> whether we should do anything wit
Michael Paquier writes:
> On Fri, Apr 09, 2021 at 08:52:20AM +0200, Fabien COELHO wrote:
>> There is not a single test of "ctrl-c" which would have caught this trivial
>> and irritating regression. ISTM that a TAP test is doable. Should one be
>> added?
> If you can design something reliable, I w
On Fri, Apr 09, 2021 at 08:52:20AM +0200, Fabien COELHO wrote:
> There is not a single test of "ctrl-c" which would have caught this trivial
> and irritating regression. ISTM that a TAP test is doable. Should one be
> added?
If you can design something reliable, I would welcome that.
--
Michael
... btw, Coverity also doesn't like this fragment of the patch:
/srv/coverity/git/pgsql-git/postgresql/src/bin/psql/common.c: 1084 in
ShowNoticeMessage()
1078 static void
1079 ShowNoticeMessage(t_notice_messages *notes)
1080 {
1081PQExpBufferData *current = notes->in_flip
Coverity has pointed out another problem with this patch:
/srv/coverity/git/pgsql-git/postgresql/src/bin/psql/common.c: 1425 in
SendQuery()
1419/*
1420 * Do nothing if they are messing with
savepoints themselves:
1421
Yep, it looks much better. I found it strange that the later did a reset but
was not doing the set.
Attached v2 does as you suggest.
Close enough. I was thinking about this position of the attached,
which is more consistent with the rest.
Given the structural complexity of the function, th
On 2021-Apr-08, Fabien COELHO wrote:
> It is definitely a open item. I'm not sure where you want to add it…
> possibly the "Pg 14 Open Items" wiki page? I tried but I do not have enough
> privileges, if you can do it please proceed. I added an entry in the next CF
> in the bugfix section.
User "c
On Fri, Apr 09, 2021 at 08:47:07AM +0200, Fabien COELHO wrote:
> Yep, it looks much better. I found it strange that the later did a reset but
> was not doing the set.
>
> Attached v2 does as you suggest.
Close enough. I was thinking about this position of the attached,
which is more consistent w
Attached v2 does as you suggest.
There is not a single test of "ctrl-c" which would have caught this
trivial and irritating regression. ISTM that a TAP test is doable. Should
one be added?
--
Fabien.
Bonjour Michaël,
I was running a long query this morning and wondered why the
cancellation was suddenly broken. So I am not alone, and here you are
with already a solution :)
So, studying through 3a51306, this stuff has changed the query
execution from a sync PQexec() to an async PQsendQuer
On Fri, Apr 9, 2021 at 6:36 AM Michael Paquier wrote:
>
> On Fri, Apr 09, 2021 at 01:11:35AM +0800, Julien Rouhaud wrote:
> > On Thu, Apr 08, 2021 at 07:04:01PM +0200, Fabien COELHO wrote:
> >> It is definitely a open item. I'm not sure where you want to add it…
> >> possibly the "Pg 14 Open Items
On Fri, Apr 09, 2021 at 01:11:35AM +0800, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 07:04:01PM +0200, Fabien COELHO wrote:
>> It is definitely a open item. I'm not sure where you want to add it…
>> possibly the "Pg 14 Open Items" wiki page?
>
> Correct.
I was running a long query this morni
Bonjour Fabien,
On Thu, Apr 08, 2021 at 07:04:01PM +0200, Fabien COELHO wrote:
> >
> > Thanks for the patch Fabien. I've hit this issue multiple time and this is
> > indeed unwelcome. Should we add it as an open item?
>
> It is definitely a open item. I'm not sure where you want to add it…
> p
Bonjour Julien,
Attached a patch which attempts to fix this by moving the cancellation
cancelling request after processing results.
Thank you for your fixing. I tested and the problem has been solved
after applying your patch.
Thanks for the patch Fabien. I've hit this issue multiple time
On Thu, Apr 08, 2021 at 01:32:12AM +, shiy.f...@fujitsu.com wrote:
> > Attached a patch which attempts to fix this by moving the cancellation
> > cancelling request after processing results.
>
> Thank you for your fixing. I tested and the problem has been solved after
> applying your patch.
> Attached a patch which attempts to fix this by moving the cancellation
> cancelling request after processing results.
Thank you for your fixing. I tested and the problem has been solved after
applying your patch.
Regards,
Shi yu
Hello,
I met a problem after commit 3a51306722.
While executing a SQL statement with psql, I can't interrupt it by pressing
ctrl+c.
For example:
postgres=# insert into test select generate_series(1,1000);
^C^CINSERT 0 1000
Press ctrl+c before finishing INSERT, and psql still conti
Hi
I met a problem after commit 3a51306722.
While executing a SQL statement with psql, I can't interrupt it by pressing
ctrl+c.
For example:
postgres=# insert into test select generate_series(1,1000);
^C^CINSERT 0 1000
Press ctrl+c before finishing INSERT, and psql still continuing t
Hello Peter,
My 0.02€: I tested this updated version and do not have any comment on this
version. From my point of view it could be committed. I would not bother to
separate the test style ajustments.
Committed. The last thing I fixed was the diff in the copy2.out regression
test. The ord
On 14.03.21 10:54, Fabien COELHO wrote:
Hello Peter,
This reply was two months ago, and nothing has happened, so I have
marked the patch as RwF.
Given the ongoing work on returning multiple result sets from stored
procedures[0], I went to dust off this patch.
Based on the feedback, I put
Hello Peter,
This reply was two months ago, and nothing has happened, so I have
marked the patch as RwF.
Given the ongoing work on returning multiple result sets from stored
procedures[0], I went to dust off this patch.
Based on the feedback, I put back the titular SHOW_ALL_RESULTS option,
On 30.09.20 08:21, Michael Paquier wrote:
On Mon, Jul 20, 2020 at 07:48:42AM +0200, Fabien COELHO wrote:
Yes, indeed. I'm planning to investigate, hopefully this week.
This reply was two months ago, and nothing has happened, so I have
marked the patch as RwF.
Given the ongoing work on return
On Mon, Jul 20, 2020 at 07:48:42AM +0200, Fabien COELHO wrote:
> Yes, indeed. I'm planning to investigate, hopefully this week.
This reply was two months ago, and nothing has happened, so I have
marked the patch as RwF.
--
Michael
signature.asc
Description: PGP signature
In the meantime, here is a v9 which also fixes the behavior when using
\watch, so that now one can issue several \;-separated queries and have
their progress shown. I just needed that a few days ago and was
disappointed but unsurprised that it did not work.
This seems to break the 013_crash_r
On Sun, Jun 7, 2020 at 2:36 AM Fabien COELHO wrote:
> In the meantime, here is a v9 which also fixes the behavior when using
> \watch, so that now one can issue several \;-separated queries and have
> their progress shown. I just needed that a few days ago and was
> disappointed but unsurprised th
Hello,
This patch was marked as ready for committer, but clearly there's an
ongoin discussion about what should be the default behavoir, if this
breaks existing apps etc. So I've marked it as "needs review" and moved
it to the next CF.
The issue is that root (aka Tom) seems to be against the
Hello Tomas,
This patch was marked as ready for committer, but clearly there's an
ongoin discussion about what should be the default behavoir, if this
breaks existing apps etc. So I've marked it as "needs review" and moved
it to the next CF.
The issue is that root (aka Tom) seems to be again
This patch was marked as ready for committer, but clearly there's an
ongoin discussion about what should be the default behavoir, if this
breaks existing apps etc. So I've marked it as "needs review" and moved
it to the next CF.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
Tom Lane wrote:
> I'm not really holding my breath for that to happen, considering
> it would involve fundamental breakage of the wire protocol.
> (For example, extended query protocol assumes that Describe
> Portal only needs to describe one result set. There might be
> more issues, but
"Daniel Verite" writes:
> Yes. For instance if the stored procedures support gets improved to
> produce several result sets, how is psql going to benefit from it
> while sticking to the old way (PGresult *r = PQexec(query))
> of executing queries that discards N-1 out of N result sets?
I'm not re
Alvaro Herrera wrote:
> if this patch enables other psql features, it might be a good step
> forward.
Yes. For instance if the stored procedures support gets improved to
produce several result sets, how is psql going to benefit from it
while sticking to the old way (PGresult *r = PQexec(q
My own vote would be to use the initial patch (after applying any
unrelated changes per later review), ie. add the feature with its
disable button.
I can do that, but not if there is a veto from Tom on the feature.
I wish definite negative opinions by senior committers would be expressed
ea
Hello Tom,
This is one of the patches already marked as RFC (since September by
Alvaro). Anyone interested in actually pushing it, so that it does not
fall through to yet another commitfest?
TBH, I think we'd be better off to reject it. This makes a nontrivial
change in a very long-standing
On 2020-Jan-16, Tom Lane wrote:
> The compatibility issue could be resolved by putting in the option
> that I suppose was there at the beginning. But then we'd have to
> have a debate about which behavior would be default, and there would
> still be the question of who would find this to be an im
1 - 100 of 130 matches
Mail list logo
