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
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 |