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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Baines <mail(at)cbaines(dot)net>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Fix pg_dump --no-tablespaces for the custom format
Date: 2020-05-16 00:16:41
Message-ID: 20336.1589588201@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.)

So from my perspective, things are working fine and this patch would
break it.

If you actually want to suppress this info from getting into the
archive file, you'd have to give a very compelling reason for
breaking this behavior for other people.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-05-16 00:21:50 Re: Potentially misleading name of libpq pass phrase hook
Previous Message Alvaro Herrera 2020-05-16 00:08:22 Re: Potentially misleading name of libpq pass phrase hook