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

From Andrew Dunstan
Subject Re: Feature bug dumpall CREATE ROLE postgres
Date
Msg-id 66b8e1af-7394-acd2-882f-c7b03e981255@dunslane.net
Whole thread Raw
In response to Re: Feature bug dumpall CREATE ROLE postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 2024-02-28 We 17:53, Tom Lane wrote:
> 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 ...
>
>     


Based on no real evidence my feeling is that the incidence of that 
problem is likely to be several orders of magnitude smaller than the 
incidence of the problem complained of by the OP.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-bugs by date:

Previous
From: "Dian Fay"
Date:
Subject: `order by random()` makes select-list `random()` invocations deterministic
Next
From: Michael Paquier
Date:
Subject: Re: BUG #18363: Assert !ReindexIsProcessingIndex falsified with expression index over select from table