Re: Feature bug dumpall CREATE ROLE postgres

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Wilson <jim(at)wreath(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Feature bug dumpall CREATE ROLE postgres
Date: 2024-02-29 04:47:42
Message-ID: 66b8e1af-7394-acd2-882f-c7b03e981255@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


On 2024-02-28 We 17:53, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tender Wang 2024-02-29 05:25:20 Re: "type with xxxx does not exist" when doing ExecMemoize()
Previous Message Dian Fay 2024-02-29 04:45:17 `order by random()` makes select-list `random()` invocations deterministic