didier writes:
> [ 0001-Add-sqlstate-output-mode-to-VERBOSITY_v1.patch ]
Pushed with some mostly-cosmetic adjustments. The main non-cosmetic
thing I did was to adjust the logic so that if no SQLSTATE is available,
it acts like TERSE mode. Otherwise, we'd print nothing at all except
"ERROR:",
Peter Eisentraut writes:
> But now that I read the patch again, I'm not sure why this needs to
> touch libpq. The formatting of error messages in psql should be handled
> in psql.
Maybe in an ideal world that'd be the case, but psql has always just
depended on PQerrorMessage(). I don't think
On 2019-03-21 19:01, David Steele wrote:
> What do you think, Peter? Is the extra test valuable or will it cause
> unpredictable outputs as Tom and Michael predict?
Yes, I'm OK with that.
But now that I read the patch again, I'm not sure why this needs to
touch libpq. The formatting of error
On Thursday, March 21, 2019 7:47 PM, Tom Lane wrote:
> David Steele da...@pgmasters.net writes:
>
> > > > > > Why are you not including a test for \set VERBOSITY verbose?
>
> > What do you think, Peter? Is the extra test valuable or will it cause
> > unpredictable outputs as Tom and Michael
David Steele writes:
> Why are you not including a test for \set VERBOSITY verbose?
> What do you think, Peter? Is the extra test valuable or will it cause
> unpredictable outputs as Tom and Michael predict?
I'm not really sure why this is open for discussion.
regression=# \set VERBOSITY
On 2/4/19 5:54 AM, Michael Paquier wrote:
On Mon, Jan 07, 2019 at 10:44:24PM +0100, didier wrote:
On Sat, Jan 5, 2019 at 6:30 PM Tom Lane wrote:
Peter Eisentraut writes:
Why are you not including a test for \set VERBOSITY verbose?
Stability of the output would be a problem ...
Yes it
On Mon, Jan 07, 2019 at 10:44:24PM +0100, didier wrote:
> On Sat, Jan 5, 2019 at 6:30 PM Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Why are you not including a test for \set VERBOSITY verbose?
>>
>> Stability of the output would be a problem ...
>>
>> Yes it could moreover the functionality
On Sat, Jan 5, 2019 at 6:30 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > Why are you not including a test for \set VERBOSITY verbose?
>
> Stability of the output would be a problem ...
>
> Yes it could moreover the functionality wasn't tested before.
Should I add one ?
Peter Eisentraut writes:
> Why are you not including a test for \set VERBOSITY verbose?
Stability of the output would be a problem ...
regards, tom lane
On 04/12/2018 13:18, didier wrote:
> diff --git a/src/test/regress/sql/psql.sql b/src/test/regress/sql/psql.sql
> index 1bb2a6e16d..64628f29a3 100644
> --- a/src/test/regress/sql/psql.sql
> +++ b/src/test/regress/sql/psql.sql
> @@ -1016,3 +1016,22 @@ select 1/(15-unique2) from tenk1 order by
On Mon, Dec 3, 2018 at 7:02 PM Pavel Stehule wrote:
> It can works :). Please, assign it to next commitfest.
Ok
From e6d0261156838b07a5a25332fa0121d6d5c5 Mon Sep 17 00:00:00 2001
From: didier
Date: Mon, 3 Dec 2018 19:20:54 +0100
Subject: [PATCH] Add sqlstate output mode to VERBOSITY
po 3. 12. 2018 v 18:57 odesílatel didier napsal:
> On Mon, Dec 3, 2018 at 5:51 PM Tom Lane wrote:
>
> > No, it's in libpq, so you'd have to touch that not the server.
> libpq, not as bad as the server but nonetheless maybe a bit too much for
> this.
> Is adding value in library contract?
>
>
On Mon, Dec 3, 2018 at 5:51 PM Tom Lane wrote:
> No, it's in libpq, so you'd have to touch that not the server.
libpq, not as bad as the server but nonetheless maybe a bit too much for this.
Is adding value in library contract?
Anyway. attached a POC adding a new value to VERBOSITY (hopefully
didier writes:
> Yep, name is bad, but I'm not sure about VERBOSITY, isn't it
> controlling output from the server not the client?
No, it's in libpq, so you'd have to touch that not the server.
I agree with Andrew's thought, and would further say that just
"\set VERBOSITY sqlstate" would be a
Yep, name is bad, but I'm not sure about VERBOSITY, isn't it
controlling output from the server not the client?
You may want to set both VERBOSITY to 'verbose' and ECHO_ERROR to
'none' then in script do
SELECT -- no error output
\if :ERROR
-- do something with LAST_ERROR_MESSAGE
On Mon,
po 3. 12. 2018 v 16:49 odesílatel Andrew Gierth
napsal:
> > "didier" == didier writes:
>
> didier> Attached a POC adding a new variable ECHO_ERROR
> didier> \set ECHO_ERROR text|none|psqlstate
>
> I wouldn't have called it that. Possibly another option to the existing
> VERBOSITY
> "didier" == didier writes:
didier> Attached a POC adding a new variable ECHO_ERROR
didier> \set ECHO_ERROR text|none|psqlstate
I wouldn't have called it that. Possibly another option to the existing
VERBOSITY variable? \set VERBOSITY sqlstate_only or something of that
ilk (it's already
Attached a POC adding a new variable ECHO_ERROR
\set ECHO_ERROR text|none|psqlstate
On Mon, Dec 3, 2018 at 2:47 AM Andrew Gierth
wrote:
>
> > "Tom" == Tom Lane writes:
>
> Tom> I don't buy that argument. We use psql's normal display in all the
> Tom> regular regression tests, and it's not
> "Tom" == Tom Lane writes:
Tom> I don't buy that argument. We use psql's normal display in all the
Tom> regular regression tests, and it's not a big maintenance problem.
The regular regression tests have the advantage that they don't need to
work across pg versions.
It is more of a
Currently with 10 head
ERROR: could not determine polymorphic type because input has type unknown
With 9 head
ERROR: could not determine polymorphic type because input has type "unknown"
Another option could be: set display error to none and let user's
script do some regular expression on pdsl
ne 2. 12. 2018 v 16:56 odesílatel Tom Lane napsal:
> didier writes:
> > Currently on error psql is printing Postgres' PQerrorMessage text, but
> > there's no guarantee these messages are constant between Postgres
> > versions and it's a pain when using psql for writing regression tests,
>
> I
didier writes:
> Currently on error psql is printing Postgres' PQerrorMessage text, but
> there's no guarantee these messages are constant between Postgres
> versions and it's a pain when using psql for writing regression tests,
I don't buy that argument. We use psql's normal display in all the
ne 2. 12. 2018 v 15:34 odesílatel didier napsal:
> Hi,
>
> Currently on error psql is printing Postgres' PQerrorMessage text, but
> there's no guarantee these messages are constant between Postgres
> versions and it's a pain when using psql for writing regression tests,
>
> Prior
> Disallow
Hi,
Currently on error psql is printing Postgres' PQerrorMessage text, but
there's no guarantee these messages are constant between Postgres
versions and it's a pain when using psql for writing regression tests,
Prior
Disallow setting client_min_messages higher than ERROR.
a bad workaround
24 matches
Mail list logo
