> On Monday, January 22, 2018, Stephen Frost <sfrost@snowman.net> wrote:
>> In the end, I feel like this patch has actually been through the ringer
>> and back because it was brought up in the context of solving a problem
>> that we'd all like to fix in a better way. Had it been simply dropped
>> on us as a "I'd like to not have comments in my pg_dump output and
>> here's a patch to allow me to do that" I suspect it would have been
>> committed without anywhere near this level of effort.
Indeed ... but it was *not* presented that way, and that's what makes
this somewhat of a difficult call. You and Robert argued that there were
valid use-cases, but I feel like that was somewhat of an after-the-fact
justification, rather than an actual organic feature request.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> +0; but recognizing our users are going to remain annoyed by the existing
> problem and that telling them that this is the answer will not sit well.
FWIW, today's pg_dump refactoring got rid of one of the use-cases for
this, namely the COMMENT ON DATABASE aspect. We got rid of another aspect
(creating/commenting on the public schema) some time ago, via a method
that was admittedly a bit of a hack but got the job done. What seems to
be left is that given a default installation, pg_dump will emit a
"COMMENT ON EXTENSION plpgsql" that can't be restored by an unprivileged
user ... as well as a "CREATE EXTENSION IF NOT EXISTS plpgsql", which is
an utter kluge. Maybe we can think of a rule that will exclude plpgsql
from dumps without causing too much havoc.
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.)
regards, tom lane