Re: pg_dump new feature: exporting functions only. Bad or good idea ?

On Fri, Mar 25, 2022 at 2:55 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> >> On 25 Mar 2022, at 19:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I'd vote for changing the behavior of --table rather than trying to
> >> be bug-compatible with this decision.
>
> > Agreed. Question is what to do for "-t pg_class", should we still forbid
> > dumping system catalogs when they are pattern matched without wildcard
> or is
> > should that be ok? And should this depend on if "-n pg_catalog" is used?
>
> I don't think there's anything really wrong with just "we won't dump
> system objects, full stop"; I don't see much use-case for doing that
> except maybe debugging, and even that is a pretty thin argument.
>

+1

We could bug-fix in a compromise if we felt compelled by a user complaint
but I don't foresee any compelling ones for this. The catalogs are
implementation details that should never have been exposed in this manner
in the first place.

If we want to choose the other position I would just go with
"--[no]-system-objects" options to toggle whether pattern matching grabs
them by default (defaulting to no) and if someone wants to enable them for
only specific object types they can --system-objects and then
--exclude-type='pg_catalog' any that shouldn't be enabled.

The documentation already says that the include options ignore -n/-N so the
solution that breaks this rule seems less appealing at a cursory glance.

David J.