Re: pg_dump not dumping default_text_search_config WAI?

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

In response to

Browse pgsql-hackers by date

  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