From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | neil(at)postgrescompare(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: BUG #14701: pg_dump fails to dump pg_catalog schema |
Date: | 2017-06-12 00:19:52 |
Message-ID: | 10396.1497226792@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
neil(at)postgrescompare(dot)com writes:
> Just installed the beta of v10 on my Mac and attempted to dump the contents
> of pg_catalog as follows.
> ./bin/pg_dump -U postgres -n pg_catalog
> pg_dump: unrecognized collation provider: d
The reason for that is that the "default" collation has collprovider =
'd', which pg_dump doesn't know what to do with, and I'm not sure it
could do anything sensible with given that CREATE COLLATION doesn't
accept anything corresponding to that. OTOH, I'm not real sure what
is the point of the 'd' value, because I can find no code in the backend
that deals with COLLPROVIDER_DEFAULT; it seems at best rather accidental
that the entry works at all. We could get rid of the 'd' and have
some hack to make initdb insert the appropriate 'i' or 'c' value
based on USE_ICU, perhaps. Alternatively, I think that CREATE COLLATION
ought to grow the ability to accept "provider = default" and pg_dump
should use that. Peter?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-06-12 03:17:08 | Re: Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog |
Previous Message | Joe Conway | 2017-06-11 15:52:55 | Re: BUG #14682: row level security not work with partitioned table |