Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Robins Tharakan <tharakan(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump
Date: 2018-01-23 16:41:23
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> The most obvious hack is just to exclude PL objects with OIDs below 16384
>> from the dump. An issue with that is that it'd lose any nondefault
>> changes to the ACL for plpgsql, which seems like a problem. On the
>> other hand, I think the rule we have in place for the public schema is
>> preventing dumping local adjustments to that, and there have been no
>> complaints. (Maybe I'm wrong and the initacl mechanism handles that
>> case? If so, seems like we could get it to handle local changes to
>> plpgsql's ACL as well.)

> Both the public schema and plpgsql's ACLs should be handled properly
> (with local changes preserved) through the pg_init_privs system. I'm
> not sure what you're referring to regarding a rule preventing dumping
> local adjustments to the public schema, as far as I can recall we've
> basically always supported that.

I went looking and realized that actually what we're interested in here
is the plpgsql extension, not the plpgsql language ... and in fact the
behavior I was thinking of is already there, except for some reason it's
only applied during binary upgrade. So I think we should give serious
consideration to the attached, which just removes the binary_upgrade
condition (and adjusts nearby comments). With this, I get empty dumps
for the default state of template1 and postgres, which is what one
really would expect. And testing shows that if you modify the ACL
of language plpgsql, that does still come through as expected.

(Note: this breaks the parts of the pg_dump regression tests that
expect to see "CREATE LANGUAGE plpgsql". I've not bothered to update
those, pending the decision on whether to do this.)

regards, tom lane

Attachment Content-Type Size
do-not-dump-built-in-extensions-wip.patch text/x-diff 2.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-23 16:46:48 Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Previous Message Peter Eisentraut 2018-01-23 16:40:01 Re: PATCH: Configurable file mode mask