|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||"Daniel Verite" <daniel(at)manitou-mail(dot)org>|
|Subject:||Re: Changes to pg_dump/psql following collation "C" in the catalog|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
"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
>> 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
|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|