Re: Attaching error cursor position to invalid constant values

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Attaching error cursor position to invalid constant values
Дата
Msg-id 29336.1220159585@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Attaching error cursor position to invalid constant values  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Attaching error cursor position to invalid constant values
Список pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> "Brendan Jurd" <direvus@gmail.com> writes:
>> What about implementing some kind of cutoff point for query length.

> Perhaps there could be a psql option to control whether to show the error
> position and perhaps that setting could be based on the length of the query or
> how many lines are in it but that seems unnecessarily baroque.

Yeah, if we were to do something like that it should clearly be a
client-side decision.

> It doesn't seem outrageously chatty to me. Better to err on the side of being
> too helpful to the user than not helpful enough.

Currently, for the things we show an error cursor for, there's no lower
limit on query length, eg

regression=# select nosuchcol from int4_tbl;
ERROR:  column "nosuchcol" does not exist
LINE 1: select nosuchcol from int4_tbl;              ^
regression=# 

and I don't recall having heard any complaints about that.  I was just a
bit shell-shocked by the number of regression test diffs my patch
generated.  But on looking closer, the reason is the intentional testing
of bad values in a lot of the datatype-specific tests.  So that's
probably not a good indicator of how chatty it'll seem to regular users.
        regards, tom lane


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

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: Attaching error cursor position to invalid constant values