Re: Feature bug dumpall CREATE ROLE postgres - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Feature bug dumpall CREATE ROLE postgres
Date
Msg-id 2572128.1709160792@sss.pgh.pa.us
Whole thread Raw
In response to Re: Feature bug dumpall CREATE ROLE postgres  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Feature bug dumpall CREATE ROLE postgres
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Feature bug dumpall CREATE ROLE postgres
Next
From: ocean_li_996
Date:
Subject: Re:Re: BUG #18369: logical decoding core on AssertTXNLsnOrder()