Re: Changes to pg_dump/psql following collation "C" in the catalog

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

In response to

Responses

Browse pgsql-hackers by date

  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