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

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: [proposal] Add an option for returning SQLSTATE in psql error message
Дата
Msg-id em5EhFxaurg1JEm8EdSAPFUuTdp7gj4cQMFByGDvRrmXuYZjyAYwheFQCjodb_KnBDhKpLhHm9aL85xGLvdmPlL8P2_vcTDqtXTu_x0CaJY=@yesql.se
обсуждение исходный текст
Ответ на Re: [proposal] Add an option for returning SQLSTATE in psql error message  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thursday, March 21, 2019 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> David Steele david@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 predict?
>
> I'm not really sure why this is open for discussion.
>
> regression=# \set VERBOSITY verbose
> regression=# select 1/0;
> ERROR: 22012: division by zero
> LOCATION: int4div, int.c:824
>
> It's not going to be tolerable to have to adjust such a test anytime
> somebody adds or removes lines in whichever backend file throws the
> tested-for error (never mind more-substantial refactoring such as
> moving the ereport call to a different function or file). I also
> believe that the reported line number will vary across compilers
> even without that: IME you might get either the starting or ending
> line number of the ereport() construct.

In GPDB we have to handle variable output in tests similar to this (but
for very different reasons), and unless there is a big gain elsewhere
from having variable test output I would advise against it. It adds a
fair bit of complexity and another moving part which can mask subtle
test failures.

cheers ./daniel


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [proposal] Add an option for returning SQLSTATE in psql error message
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_basebackup ignores the existing data directory permissions