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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on
Date: 2014-11-21 19:44:04
Message-ID: 28590.1416599044@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-11-21 19:45:31 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Previous Message Alvaro Herrera 2014-11-21 19:20:53 Re: pg_multixact not getting truncated