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