On Thu, Jan 16, 2020 at 01:08:16PM -0500, Tom Lane wrote:
Tomas Vondra writes:
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
Tomas Vondra writes:
> 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
Hi,
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?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support,
The below addition can be removed, it seems to be duplicate:
Indeed. I'm unsure how this got into the patch, probably some rebase mix-up.
Attached v7 removes the duplicates.
Attached patch v8 is a rebase.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out
On Fri, Sep 20, 2019 at 1:41 PM Fabien COELHO wrote:
>
>
> > Should we add function header for the below function to maintain the
> > common standard of this file:
>
> Yes. Attached v6 does that.
>
Thanks for fixing it.
The below addition can be removed, it seems to be duplicate:
@@ -3734,6
Should we add function header for the below function to maintain the
common standard of this file:
Yes. Attached v6 does that.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/contrib/pg_stat_statements/expected/pg_stat_statements.out
index
On Fri, Sep 13, 2019 at 1:01 AM Alvaro Herrera wrote:
>
> This v6 is just Fabien's v5, rebased over a very minor conflict, and
> pgindented. No further changes. I've marked this Ready for Committer.
>
Should we add function header for the below function to maintain the
common standard of this
This v6 is just Fabien's v5, rebased over a very minor conflict, and
pgindented. No further changes. I've marked this Ready for Committer.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git
Hello Kyotaro-san,
Thanks. I looked this more closely.
Indeed! Thanks for this detailed review.
+ * Marshal the COPY data. Either subroutine will get the
+ * connection out of its COPY state, then call PQresultStatus()
+ * once and report any error.
This comment doesn't explain what the
Hello.
On 2019/07/29 6:36, Fabien COELHO wrote:>
>> Thanks for the feedback. Attached v3 with further documentation updates.
>
> Attached v4 also fixes pg_stat_statements non regression tests, per pg
> patch tester travis run.
Thanks. I looked this more closely.
+ * Marshal the COPY data.
Hello, Fabien.
At Fri, 26 Jul 2019 08:19:47 + (GMT), Fabien COELHO
wrote in
>
> Hello Kyotaro-san,
>
> >> Attached a v2 for the always-show-all-results variant. Thanks for the
> >> debug!
> >
> > I have some comments on this patch.
> >
> > I'm +1 for always output all results without
Thanks for the feedback. Attached v3 with further documentation updates.
Attached v4 also fixes pg_stat_statements non regression tests, per pg
patch tester travis run.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out
Fabien COELHO wrote:
> sh> /usr/bin/psql
> psql (12beta2 ...)
> fabien=# \set FETCH_COUNT 2
> fabien=# SELECT 1234 \; SELECT 5432 ;
> fabien=#
>
> same thing with pg 11.4, and probably down to every version of postgres
> since the feature was implemented...
>
> I think that
Hello Kyotaro-san,
Attached a v2 for the always-show-all-results variant. Thanks for the
debug!
I have some comments on this patch.
I'm +1 for always output all results without having knobs.
That makes 4 opinions expressed towards this change of behavior, and none
against.
Hello.
At Thu, 25 Jul 2019 21:42:11 + (GMT), Fabien COELHO
wrote in
>
> Bonsoir Daniel,
>
> > FYI you forgot to remove that bit:
> >
> > + "SINGLELINE|SINGLESTEP|SHOW_ALL_RESULTS"))
>
> Indeed. I found another such instance in "help.c".
>
> > Also copydml does not seem to be exercised
Bonsoir Daniel,
FYI you forgot to remove that bit:
+ "SINGLELINE|SINGLESTEP|SHOW_ALL_RESULTS"))
Indeed. I found another such instance in "help.c".
Also copydml does not seem to be exercised with combined
queries, so do we need this chunk:
--- a/src/test/regress/sql/copydml.sql
Yep,
Fabien COELHO wrote:
> Attached a "do it always version", which does the necessary refactoring.
> There is seldom new code, it is rather moved around, some functions are
> created for clarity.
Thanks for the update!
FYI you forgot to remove that bit:
--- a/src/bin/psql/tab-complete.c
Bonjour Daniel,
I kind of agree as well, but I was pretty sure that someone would complain
if the current behavior was changed.
If queries in a compound statement must be kept silent,
they can be converted to CTEs or DO-blocks to produce the
same behavior without having to configure anything
Fabien COELHO wrote:
> >> I'd go further and suggest that there shouldn't be a variable
> >> controlling this. All results that come in should be processed, period.
> >
> > I agree with that.
>
> I kind of agree as well, but I was pretty sure that someone would complain
> if the current
Hello Peter,
I'd go further and suggest that there shouldn't be a variable
controlling this. All results that come in should be processed, period.
I agree with that.
I kind of agree as well, but I was pretty sure that someone would complain
if the current behavior was changed.
Should I
On 2019-05-15 18:41, Daniel Verite wrote:
> I'd go further and suggest that there shouldn't be a variable
> controlling this. All results that come in should be processed, period.
I agree with that.
> It's not just about \; If the ability of CALL to produce multiple
> resultsets gets implemented
Here is a v3 which fixes \errverbose, hopefully.
V5 is a rebase and an slightly improved documentation.
It was really v4. v5 is a rebase.
--
Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index c6c20de243..a7557af0fe 100644
---
Here is a v3 which fixes \errverbose, hopefully.
V5 is a rebase and an slightly improved documentation.
--
Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index b86764003d..4a1b562f24 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++
Re-bonjour Daniel,
This attached version does:
- ensure that warnings appear just before its
- add the entry in psql's help
- redefine the function boundary so that timing is cleaner
- include somehow improved tests
\errverbose seems to no longer work with the patch:
Here is a v3 which
Bonjour Daniel,
IMHO this new setting should be on by default: few people know about \; so
it would not change anything for most, and I do not see why those who use
it would not be interested by the results of all the queries they asked for.
I agree with your opinion.
Ok. I did not yet
Fabien COELHO wrote:
> >> IMHO this new setting should be on by default: few people know about \; so
> >> it would not change anything for most, and I do not see why those who use
> >> it would not be interested by the results of all the queries they asked
> >> for.
> > I agree with your
Hello Aya-san,
Thanks for this review.
There is space (+--' '). Please delete it. It is cause of regression test
failed.
Indeed, unsure how I could do that. Fixed.
IMHO this new setting should be on by default: few people know about \; so
it would not change anything for most, and I do
Hi Fabien,
I review your patch.
> Add a few tests for the new feature.
+++ b/src/test/regress/expected/psql.out
@@ -4729,3 +4729,46 @@ drop schema testpart;
set search_path to default;
set role to default;
drop role testrole_partitioning;
+--
There is space (+--' '). Please delete it. It
101 - 128 of 128 matches
Mail list logo
