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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: neil(at)postgrescompare(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14701: pg_dump fails to dump pg_catalog schema
Date: 2017-06-12 16:18:06
Message-ID: 19748.1497284286@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 6/11/17 20:19, Tom Lane wrote:
>> 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?

Hmm, well, actually not --- it certainly wouldn't make any sense to
try to create pg_class again, for instance. You could imagine changing
the schema name and creating a clone of all the objects, but that
only works for objects with schema-qualified names. So mostly this
is only useful for documentation, which I think is Neil's use-case
anyway.

That leads to the idea that it would be okay to let pg_dump print
"provider = default" but *not* let CREATE COLLATION accept that.
If we did that and also disallowed cloning the default collation,
then we'd have the property that only the original default collation
has provider 'd', and the existing code would continue to work.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeff Janes 2017-06-12 16:20:41 Re: BUG #14664: Nonsensical join selectivity estimation despite n_distinct
Previous Message Peter Eisentraut 2017-06-12 16:02:47 Re: BUG #14701: pg_dump fails to dump pg_catalog schema