add --sequence-data to pg_dumpall

I noticed that I forgot to add --sequence-data to pg_dumpall in commit
9c49f0e, which added the same option to pg_dump. This option is primarily
intended for use by pg_upgrade, so we will need it if/when we teach
pg_upgrade to use pg_dumpall to dump the databases. (Right now pg_upgrade
directly calls pg_dump on each database.)

Assuming we want this patch, should we apply it to v18? It's arguably an
oversight in the pg_dump --sequence-data commit, and pg_dumpall will just
pass the option through to pg_dump, but otherwise there's not a really
strong reason it can't wait.

--
nathan

On Tue, Apr 29, 2025 at 03:55:08PM -0500, Nathan Bossart wrote:
> I noticed that I forgot to add --sequence-data to pg_dumpall in commit
> 9c49f0e, which added the same option to pg_dump. This option is primarily
> intended for use by pg_upgrade, so we will need it if/when we teach
> pg_upgrade to use pg_dumpall to dump the databases. (Right now pg_upgrade
> directly calls pg_dump on each database.)
>
> Assuming we want this patch, should we apply it to v18? It's arguably an
> oversight in the pg_dump --sequence-data commit, and pg_dumpall will just
> pass the option through to pg_dump, but otherwise there's not a really
> strong reason it can't wait.

This reminds me of, that fixed a similar defect in pg_dumpall
following the addition of an option in pg_dump where the former was
forgotten:
https://www.postgresql.org/message-id/YKHC%2BqCJvzCRVCpY%40paquier.xyz

I agree with applying that to v18 now and treat it as a defect rather
than wait for v19 and treat this patch as a new feature. Bonus points
for the patch being straight-forward.
--
Michael

On Wed, Apr 30, 2025 at 09:29:59AM +0900, Michael Paquier wrote:
> On Tue, Apr 29, 2025 at 03:55:08PM -0500, Nathan Bossart wrote:
>> Assuming we want this patch, should we apply it to v18? It's arguably an
>> oversight in the pg_dump --sequence-data commit, and pg_dumpall will just
>> pass the option through to pg_dump, but otherwise there's not a really
>> strong reason it can't wait.
>
> This reminds me of, that fixed a similar defect in pg_dumpall
> following the addition of an option in pg_dump where the former was
> forgotten:
> https://www.postgresql.org/message-id/YKHC%2BqCJvzCRVCpY%40paquier.xyz
>
> I agree with applying that to v18 now and treat it as a defect rather
> than wait for v19 and treat this patch as a new feature. Bonus points
> for the patch being straight-forward.

Since there's precedent, I'll plan on committing this in the next few days
unless someone objects. I've added the rest of the RMT to this thread,
too, just in case.

--
nathan

On Wed, Apr 30, 2025 at 02:52:27PM -0500, Nathan Bossart wrote:
> Since there's precedent, I'll plan on committing this in the next few days
> unless someone objects. I've added the rest of the RMT to this thread,
> too, just in case.

I brought this up in the RMT meeting today, and everyone was fine with
committing it for v18. I'll plan on doing so later this week.

--
nathan

On Tue, May 06, 2025 at 11:39:33AM -0500, Nathan Bossart wrote:
> I brought this up in the RMT meeting today, and everyone was fine with
> committing it for v18. I'll plan on doing so later this week.

Committed.

--
nathan