Re: [doc] clarify behaviour of pg_dump's -t/--table option with non-tables

From: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [doc] clarify behaviour of pg_dump's -t/--table option with non-tables
Date: 2020-10-07 00:48:39
Message-ID: CAB8KJ=jdSbxEg-ZfBT2rA0pNkyh0rSNZQin9ySmEELxsBMiz6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2020年10月6日(火) 22:48 Magnus Hagander <magnus(at)hagander(dot)net>:
>
> On Tue, Oct 6, 2020 at 3:45 PM Ian Lawrence Barwick <barwick(at)gmail(dot)com> wrote:
>>
>> 2020年10月6日(火) 21:58 Ian Lawrence Barwick <barwick(at)gmail(dot)com>:
>> >
>> > Hi
>> >
>> > Recently I ran into a case where someone was wondering why it was not
>> > possible to dump the contents of a view, even though the documentation [1]
>> > seems to imply this is possible.
>> >
>> > Currently it says:
>> >
>> > Dump only tables with names matching pattern. For this purpose, "table"
>> > includes views, materialized views, sequences, and foreign tables.
>> >
>> > The attached patch attempts to clarify that only definitions of those objects
>> > will be dumped, and also mentions that dumping foreign table data requires the
>> > --include-foreign-data option.
>> >
>> > I suggest backpatching any changes to Pg13 where the --include-foreign-data
>> > option was added.
>> >
>> > [1] https://www.postgresql.org/docs/current/app-pgdump.html
>>
>> Better version attached.
>
>
> Argh, perfect timing. I'll update with your new version :)

Whoops, wasn't expecting such a quick response. Thanks!

FWIW, I sent in another patch suggesting removal of an ancient
backwards compatibility
"Note" under the same -t/--tables option description [1].

[1] https://www.postgresql.org/message-id/flat/CAB8KJ%3DjYHgnxLLZSNJz7gBTck4TxomngCmGkw3nEMSNF0yL6wA%40mail.gmail.com

Regards

Ian Barwick

--
EnterpriseDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2020-10-07 00:51:00 Re: Parallel INSERT (INTO ... SELECT ...)
Previous Message Mark Dilger 2020-10-06 23:20:22 Re: new heapcheck contrib module