Re: BUG #16265: psql shows (unfolded) relation name in quotes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jltallon(at)adv-solutions(dot)net
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16265: psql shows (unfolded) relation name in quotes
Date: 2020-02-19 15:44:49
Message-ID: 18665.1582127089@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> -------------------
> test=> \d+ Schedule
> Did not find any relation named "Schedule".
> -------------------
> EXPECTED:
> -------------------
> test=> \d+ Schedule
> Did not find any relation named "schedule".
> -------------------

Yeah, it just reports what you typed. The difficulty in doing differently
is that what you typed might not be *meant* to be interpreted literally,
because it's a pattern not a simple name. What should we do for example
with

regression=# \d+ foo*
Did not find any relation named "foo*".

A more interesting example, perhaps, is that these don't mean the same
thing:

regression=# \d+ "Foo*"
Did not find any relation named ""Foo*"".
regression=# \d+ "Foo"*
Did not find any relation named ""Foo"*".

(If I had a table named "Foot", the first case wouldn't find it but
the second would.) I'm not clear on how we could report a post-processed
version of the input that would distinguish these in a non-confusing way.

Part of the issue is that the double-quote characters are being used in
two different ways. The ones that the error message is wrapping around
the regurgitated input are not to be confused with quotes used in the
input; they're just there to separate the fixed and variable parts of
the message. This is a little easier to follow in some other languages
where different quoting characters are used in error messages, but in
English we've concluded we just have to live with it.

tl;dr: it's not that obvious what would be an improvement here.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-02-19 16:05:05 Re: BUG #16266: Server crash on SELECT event_trigger-returning function
Previous Message ahsan hadi 2020-02-19 13:59:21 Re: DROP OWNED CASCADE vs Temp tables