From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Jeremy Schneider <schneider(at)ardentperf(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Built-in CTYPE provider |
Date: | 2024-01-11 23:36:33 |
Message-ID: | f80433139cdac73dd65c6c8841ebe70f007891f7.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-01-11 23:37:49 | Re: A recent message added to pg_upgade |
Previous Message | Michael Paquier | 2024-01-11 23:35:42 | Re: Adding facility for injection points (or probe points?) for more advanced tests |