| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_dump not dumping default_text_search_config WAI? |
| Date: | 2025-11-09 16:03:31 |
| Message-ID: | 1652071.1762704211@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> On 2025-11-09 04:06, Tom Lane wrote:
>> IIRC you'd need to use --create to prod pg_dump to produce
>> a CREATE DATABASE command as well as any database-level
>> ALTER commands.
> Is that a good approach?
Well, it's what pg_dump has always done, at least since it inherited
that work from pg_dumpall (which was even less flexible).
It's not that easy/safe to do it differently. Without --create,
pg_dump is not chartered to make a new database but only to restore
into whatever DB you've connected to. So the present approach of
issuing "ALTER DATABASE foo" commands would be completely wrong.
This could be solved if we had some kind of "ALTER CURRENT DATABASE"
command, but we don't.
Plus there's the question of how the results would interact with
any existing DB-level settings. I'm not really sure that issuing
such commands against a pre-existing DB is a good idea ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mihail Nikalayeu | 2025-11-09 18:02:00 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
| Previous Message | Mihail Nikalayeu | 2025-11-09 12:53:00 | Re: isolation tester limitation in case of multiple injection points in a single command |