Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema - Mailing list pgsql-bugs

From Tom Lane
Subject Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema
Date
Msg-id 10396.1497226792@sss.pgh.pa.us
Whole thread Raw
In response to [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema  (neil@postgrescompare.com)
Responses Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-bugs
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.  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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pgsql-bugs by date:

Previous
From: Joe Conway
Date:
Subject: Re: [BUGS] BUG #14682: row level security not work with partitionedtable
Next
From: Michael Paquier
Date:
Subject: Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog