Re: proposal: possibility to read dumped table's name from file

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: proposal: possibility to read dumped table's name from file
Дата
Msg-id A7D7ED17-A2FD-43D7-94B1-8E354B6F22A8@yesql.se
обсуждение исходный текст
Ответ на Re: proposal: possibility to read dumped table's name from file  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: possibility to read dumped table's name from file  (Erik Rijkers <er@xs4all.nl>)
Список pgsql-hackers
> On 20 Nov 2023, at 06:20, Pavel Stehule <pavel.stehule@gmail.com> wrote:

> I was pondering replacing the is_include handling with returning an enum for
> the operation, to keep things more future proof in case we add more operations
> (and also a bit less magic IMHO).
>
> +1
>
> I did it.

Nice, I think it's an improvement.

+           <literal>extension</literal>: data on foreign servers, works like
+           <option>--extension</option>. This keyword can only be
+           used with the <literal>include</literal> keyword.
This seems like a copy-pasteo, fixed in the attached.

I've spent some time polishing this version of the patch, among other things
trying to make the docs and --help screen consistent across the tools.  I've
added the diff as a txt file to this email (to keep the CFbot from applying
it), it's mainly reformatting a few comments and making things consistent.

The attached is pretty close to a committable patch IMO, review is welcome on
both the patch and commit message.  I tried to identify all reviewers over the
past 3+ years but I might have missed someone.

--
Daniel Gustafsson


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_class.reltuples of brin indexes
Следующее
От: Nathan Bossart
Дата:
Сообщение: common signal handler protection