Re: Built-in CTYPE provider - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Built-in CTYPE provider
Date
Msg-id f80433139cdac73dd65c6c8841ebe70f007891f7.camel@j-davis.com
Whole thread Raw
In response to Re: Built-in CTYPE provider  (Jeremy Schneider <schneider@ardentperf.com>)
List pgsql-hackers
On Tue, 2024-01-09 at 14:17 -0800, Jeremy Schneider wrote:
> I think we missed something in psql, pretty sure I applied all the
> patches but I see this error:
>
> =# \l
> ERROR:  42703: column d.datlocale does not exist
> LINE 8:   d.datlocale as "Locale",
>           ^
> HINT:  Perhaps you meant to reference the column "d.daticulocale".
> LOCATION:  errorMissingColumn, parse_relation.c:3720

I think you're connecting to a patched server with an older version of
psql, so it doesn't know the catalog column was renamed.

pg_dump and pg_upgrade don't have that problem because they throw an
error when connecting to a newer server.

But for psql, that's perfectly reasonable to connect to a newer server.
Have we dropped or renamed catalog columns used by psql backslash
commands before, and if so, how do we handle that?

I can just not rename that column, but that's a bit frustrating because
it means I'd need to add a new column to pg_database, which seems
redundant.


Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Adding facility for injection points (or probe points?) for more advanced tests
Next
From: Michael Paquier
Date:
Subject: Re: A recent message added to pg_upgade