On 6/11/17 20:19, Tom Lane wrote:
> neil@postgrescompare.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.
Conceptually, the locale code works like this:
if provider == d strcoll()
else if provider == c strcoll_l()
else if provider == i ucol_strcoll()
[else apparently dubious here ...]
But actually the code checks for DEFAULT_COLLATION_OID instead of
provider == 'd', so having another collation with provider 'd' isn't
going to do anything useful.
Maybe it would actually be vaguely useful to change that around, now
that I think about it.
> Alternatively, I think that CREATE COLLATION
> ought to grow the ability to accept "provider = default" and pg_dump
> should use that.
We could probably do that at least in pg_dump. What are the
expectations for pg_catalog schema dumps? Are they supposed to be
restorable?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
