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

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

In response to

Responses

Browse pgsql-bugs by date

  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