Re: BUG #14701: pg_dump fails to dump pg_catalog schema

On 6/11/17 20:19, Tom Lane wrote:
> 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.

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