From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Jim Wilson <jim@wreath.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: Feature bug dumpall CREATE ROLE postgres
In-reply-to: <4f7760bd-243b-6eb1-4c4d-de07200012f9@dunslane.net>
References: 
 <CABboei8cKxParK=nGwjHp0i=5xdn9YtkUQAo=_vuGm-F8X46gw@mail.gmail.com>
 <2149099.1709064762@sss.pgh.pa.us>
 <8663cc11-4a1c-68fa-d950-fdc863f28f4b@dunslane.net>
 <2549130.1709159773@sss.pgh.pa.us>
 <4f7760bd-243b-6eb1-4c4d-de07200012f9@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Wed, 28 Feb 2024 17:47:22 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2572127.1709160792.1@sss.pgh.pa.us>
Date: Wed, 28 Feb 2024 17:53:12 -0500
Message-ID: <2572128.1709160792@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2572128.1709160792%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2024-02-28 We 17:36, Tom Lane wrote:
>> Hmm ... pg_dump has never used any DO blocks in its output, and
>> I'm not sure it's a great idea to start.  Seems like the kind of
>> decision we could regret down the road, given the possible need
>> for pg_restore to parse the output.

> This is only for pg_dumpall. pg_restore shouldn't care.

Yeah, fair point.  I've long thought that we should get pg_dumpall
to emit something more structured than "big SQL script", but I'm
not holding my breath for that to happen.

Still, I'm a bit leery of the idea.  Isn't plpgsql supposed to be
optional/droppable?  I guess we could tell people who don't want it
that they can't drop it until after restoring their old data,
but still ...

			regards, tom lane