On Sat, 16 May 2020 at 04:20, Christopher Baines <m...@cbaines.net> wrote:
> > Tom Lane <t...@sss.pgh.pa.us> writes: > > > Christopher Baines <m...@cbaines.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
