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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
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 17:03:19
Message-ID: 24143.1554483799@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
>> 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.

Yeah, it's good practice to make a CF entry to ensure the patch doesn't
slip through the cracks. There's an awful lot of traffic on pgsql-hackers
these days...

>> 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.

Pushed with some fiddling with the comments, and changing the collation
names to be schema-qualified for paranoia's sake.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-04-05 17:03:49 Re: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Previous Message Andres Freund 2019-04-05 16:51:01 Re: Pluggable Storage - Andres's take