From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Changes to pg_dump/psql following collation "C" in the catalog |
Date: | 2019-04-05 13:03:37 |
Message-ID: | 1f34d7f9-deba-4ddb-b805-e9b608b0defd@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Hm, if that's as much as we have to touch, I think there's a good
> argument for squeezing it into v12 rather than waiting. The point
> here is mostly to avoid a behavior change from pre-v12
Yes. I was mentioning the next CF because ISTM that nowadays
non-committers are expected to file patches in there, committers
picking up patches both in the current and next CF based on
their evaluation of priorities.
But if you plan to process this one shortly, a CF entry is probably
superfluous.
> Just looking at the patch, I wonder whether it doesn't need some
> server-version checks. At the very least this would break with
> pre-9.1 servers, which lack COLLATE altogether.
PFA a new version adding the clause for only 12 and up, since the
previous versions are not concerned, and as you mention, really old
versions would fail otherwise.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
Attachment | Content-Type | Size |
---|---|---|
processSQLNamePattern-using-db-collation-v2.diff | text/x-patch | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-04-05 13:10:31 | Re: Re: A separate table level option to control compression |
Previous Message | Stephen Frost | 2019-04-05 12:48:03 | Re: [PATCH v20] GSSAPI encryption support |