From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
cc: Greg Sabino Mullane <htamfids@gmail.com>,
        Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
        Corey Huinker <corey.huinker@gmail.com>,
        Andres Freund <andres@anarazel.de>,
        Michael Paquier <michael@paquier.xyz>,
        Nathan Bossart <nathandbossart@gmail.com>,
        Bruce Momjian <bruce@momjian.us>,
        Matthias van de Meent <boekewurm+postgres@gmail.com>,
        Magnus Hagander <magnus@hagander.net>,
        Stephen Frost <sfrost@snowman.net>,
        Peter Smith <smithpb2250@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        alvherre@alvh.no-ip.org, jian he <jian.universality@gmail.com>
Subject: Re: Statistics Import and Export
In-reply-to: <948dd810f942016c22ffe9bb4500677299553c59.camel@j-davis.com>
References: <CADkLM=f0a43aTd88xW4xCFayEF25g-7hTrHX_WhV40HyocsUGg@mail.gmail.com> <97b451228227c555be1a4f79c4a62ddec9a74f06.camel@j-davis.com> <CADkLM=ckXu5wzSQZ3Y_fvAaL8rZ+upZdSecBLf5FCTMj7M6T-A@mail.gmail.com> <b227c4fca29dfb893bb414ce6d84fc2377489ecc.camel@j-davis.com> <CADkLM=dRMC6t8gp9GVf6y6E_r5EChQjMAAh_vPyih_zMiq0zvA@mail.gmail.com> <y2d36zf6pl3n6ni6e4ctblu3a5iazi2dycknq53h2mjvp7lto4@hhww3h2qgdrw> <1457469.1740419458@sss.pgh.pa.us> <CADkLM=eWSv2z_DVB=psfwHitq7DbFJQaP9A46R27eARC-4OYtQ@mail.gmail.com> <cpdanvzykcb5o64rmapkx6n5gjypoce3y52hff7ocxupgpbxu4@53jmlyvukijo> <CADkLM=dX67xer59tVYMCQZ+pHAT2sCyyrUDzeDCdW_TdxqwOgA@mail.gmail.com> <curtrasm6ylt7es2ukfuals2mh5an72yzxgvyel65mw3ere7qs@nw6m4ffpo4m3> <8d13e4296408c53a93390525d0bcb906cbd13df4.camel@j-davis.com> <CACJufxHG9MBQozbJQ4JRBcRbUO+t+sx4qLZX092rS_9b4SR_EA@mail.gmail.com> <CAExHW5vf9D+8-a5_BEX3y=2y_xY9hiCxV1=C+FnxDvfprWvkng@mail.gmail.com> <768b2a237e892bf1334bdcbb066cdc1bd1368cb2.camel@j-davis.com> <CAKAnmmKCgnqcd3x!
 4Z+5yXsY7urpDS6D_NZG7pr=DYD=LHt5X4g@mail.gmail.com> <41c193c31d9144a658525b6a861e2e5d3117d88e.camel@j-davis.com> <CAKAnmmJyXoVFttrdCz=R-oZnbcJifzSidP9Z2wHO=pU4-AEb0g@mail.gmail.com> <948dd810f942016c22ffe9bb4500677299553c59.camel@j-davis.com>
Comments: In-reply-to Jeff Davis <pgsql@j-davis.com>
	message dated "Sat, 01 Mar 2025 12:48:18 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3071638.1740864219.1@sss.pgh.pa.us>
Date: Sat, 01 Mar 2025 16:23:39 -0500
Message-ID: <3071639.1740864219@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3071639.1740864219%40sss.pgh.pa.us>
Precedence: bulk

Jeff Davis <pgsql@j-davis.com> writes:
> On Sat, 2025-03-01 at 13:52 -0500, Greg Sabino Mullane wrote:
>> Also, anything trained to parse pg_dump output will have to learn
>> about the new SELECT pg_restore_ calls with their multi-line formats
>> (not 100% sure we don't have that anywhere, as things like "SELECT
>> setval" and "SELECT set_config" are single line, but there may be
>> existing things)

> That's an interesting point. What tools are currrently trying to parse
> pg_dump output?

That particular argument needs to be rejected vociferously.  Otherwise
we could never make any change at all in what pg_dump emits.  I think
the standard has to be "if you parse pg_dump output, it's on you to
cope with any legal SQL".

I do grasp Greg's larger point that this is a big change in pg_dump's
behavior and will certainly break some expectations.  I kind of lean
to the position that we'll be sad in the long run if we don't change
the default, though.  What other part of pg_dump's output is not
produced by default?

			regards, tom lane