Re: pg14 psql broke \d datname.nspname.relname

On Wed, Oct 13, 2021 at 10:40 AM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> 3a is a bit strange, when considered in the context of patterns. If db1, db2, and db3 all exist and each have a table foo.bar, and psql is connected to db1, how should the command \d db?.foo.bar behave? We have no problem with db1.foo.bar, but we do have problems with the other two. If the answer is to complain about the databases that are unconnected, consider what happens if the user writes this in a script when only db1 exists, and later the script stops working because somebody created database db2. Maybe that's not completely horrible, but surely it is less than ideal.
>
> 3b is what pg_amcheck does. It accepts database.schema.relname, and it will complain if no matching database/schema/relation can be found (unless --no-strict-names was given.)

Well, like I said, we can't treat a part that's purportedly a DB name
as a pattern, so when connected to db1, I presume the command \d
db?.foo.bar would have to behave just like \d
dskjlglsghdksgdjkshg.foo.bar. I suppose technically I'm wrong: db?
could be matched against the list of database names as a pattern, and
then we could complain only if it doesn't match exactly and only the
current DB. But I don't like adding a bunch of extra code to
accomplish nothing useful, so if we're going to match it all I think
it should just strcmp().

But I'm still not sure what the best thing to do overall is here.

--
Robert Haas
EDB: http://www.enterprisedb.com