Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema

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