Re: [PATCH] Fix pg_dump --no-tablespaces for the custom format

On Sat, 16 May 2020 at 04:20, Christopher Baines <mail(at)cbaines(dot)net> wrote:

>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Christopher Baines <mail(at)cbaines(dot)net> writes:
> >> So I'm new to poking around in the PostgreSQL code, so this is a bit of
> >> a shot in the dark. I'm having some problems with pg_dump, and a
> >> database with tablespaces. A couple of the tables are not in the default
> >> tablespace, and I want to ignore this for the dump.
> >
> > I think you've misunderstood how the pieces fit together. A lot of
> > the detail-filtering switches, including --no-tablespaces, work on
> > the output side of the "archive" format. While you can't really tell
> > the difference in pg_dump text mode, the implication for custom-format
> > output is that the info is always there in the archive file, and you
> > give the switch to pg_restore if you don't want to see the info.
> > This is more flexible since you aren't compelled to make the decision
> > up-front, and it doesn't really cost anything to include such info in
> > the archive. (Obviously, table-filtering switches don't work that
> > way, since with those there can be a really large cost in file size
> > to include unwanted data.)
> >
>
I've also had to explain a dozen times how the archive format works. Archive
format is kind of intermediary format because you can produce a plain format
using it.

[Testing some pg_dump --no-option ...]

The following objects are not included if a --no-option is used:

* grant / revoke
* comment
* publication
* subscription
* security labels

but some are included even if --no-option is used:

* owner
* tablespace

I'm wondering why there is such a distinction. We have some options:

(a) leave it as is and document that those 2 options has no effect in
pg_dump
and possibly add a warning to report if someone uses it with an archive
format;
(b) exclude owner and tablespace from archive (it breaks compatibility but
do
exactly what users expect).

I do not even consider a possibility to include all objects even if a
--no-option is used because you will have a bunch of complaints / reports.

--
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services