Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on
Дата
Msg-id 28590.1416599044@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on  (Andrew Dunstan <andrew@dunslane.net>)
Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Well, now we get things like this:

>     ERROR:  more than one function named "abc"
>     LINE 1: SELECT 'abc'::pg_catalog.regproc::pg_catalog.oid

> whereas minimal_error_message suppressed the second line. If we want to 
> preserve that older behaviour we'll have to abandon use of PSQLexec. But 
> it's not so complex that that would be a huge issue.

Yeah, the reason why we wrote that code to begin with was that there
were a bunch of user-facing error cases that would be reported by
regproc_in/regprocedure_in, and we didn't want to clutter those error
reports with the underlying queries.

I'm not sure how I feel about changing this.  Making these queries subject
to ECHO_HIDDEN seems like we're exposing them to users to some extent
anyway, and maybe it's not worth dozens of lines of code (and duplicating
large parts of PSQLexec) to avoid the extra output.  On the other hand
this output doesn't seem very nice from a fit-and-finish standpoint.
        regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_multixact not getting truncated
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg