Re: [proposal] Add an option for returning SQLSTATE in psql error message

From: didier <did447(at)gmail(dot)com>
To: pavel(dot)stehule(at)gmail(dot)com
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [proposal] Add an option for returning SQLSTATE in psql error message
Date: 2018-12-02 17:39:56
Message-ID: CAJRYxu+AJMVzsPh2=mO5rSXD8eW47Zq6TwYuNBhMG6P0rOmCrg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 variable.
On Sun, Dec 2, 2018 at 5:05 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>
>
> ne 2. 12. 2018 v 16:56 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>>
>> didier <did447(at)gmail(dot)com> 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
>> regular regression tests, and it's not a big maintenance problem.
>> If the error message changes, that's usually interesting in itself.
>
>
> our tests are not against different PostgreSQL releases. When you have a code, that should to support more PostgreSQL releases, then it is sometimes difficult.
>
>>
>> Also, if it does change, it's often because you're hitting a different
>> error-detection test, which more than likely is throwing a different
>> SQLSTATE anyway.
>>
>> Lastly, because the SQL spec has been rather miserly in assigning
>> SQLSTATEs in some areas, there are lots of cases where the same
>> SQLSTATE is used for several distinct errors; for instance
>> ERRCODE_UNDEFINED_OBJECT covers a lot of ground. Do you really
>> want your test cases to be unable to distinguish those?
>>
>> There might be a use-case for showing only SQLSTATE, but writing
>> regression tests doesn't seem like a good example.
>>
>> regards, tom lane
>>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2018-12-02 17:44:57 Re: [PATCH] Log CSV by default
Previous Message Tom Lane 2018-12-02 17:09:57 Re: [PATCH] Log CSV by default