Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on - Mailing list pgsql-hackers

From Tom Lane
Subject Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on
Date
Msg-id 28590.1416599044@sss.pgh.pa.us
Whole thread Raw
In response to Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on  (Andrew Dunstan <andrew@dunslane.net>)
Responses 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>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_multixact not getting truncated
Next
From: Tomas Vondra
Date:
Subject: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg