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

On Tue, Apr 19, 2022 at 7:00 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Apr 18, 2022 at 3:39 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> > Since there hasn't been any agreement on that point, I've just rebased
> the patch to apply cleanly against the current master:
>
> This looks OK to me. There may be better ways to do some of it, but
> there's no rule against further improving the code later. Also, since
> the issue was introduced in v14, we probably shouldn't wait forever to
> do something about it. However, there is a procedural issue here now
> that we are past feature freeze. I think someone could defensibly take
> any of the following positions:
>
> (A) This is a new feature. Wait for v16.
> (B) This is a bug fix. Commit it now and back-patch to v14.
> (C) This is a cleanup that is OK to put into v15 even after feature
> freeze but since it is a behavior change we shouldn't back-patch it.
>
> I vote for (C). What do other people think?
>
>
I vote for (B). The behavioral change for v14 turns working usage patterns
into errors where it should not have. It is a design bug and POLA
violation that should be corrected.

"""
such that the above example was
interpreted as schema=production, relation=marketing.customers.
This turns out to be highly unintuitive to users.
"""

My concern here about a behavior affecting bug fix - which we allow - is
reduced by the fact this feature is almost exclusively an interactive one.
Which supports not having only v14, and maybe v15, behave differently than
v13 and v16 when it comes to using it for expected usage patterns:

"""
We've had reports that users sometimes copy-and-paste database- and
schema-qualified relation names from the logs.
"""

David J.