Re: proposal: possibility to read dumped table's name from file - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: proposal: possibility to read dumped table's name from file
Date
Msg-id A7D7ED17-A2FD-43D7-94B1-8E354B6F22A8@yesql.se
Whole thread Raw
In response to Re: proposal: possibility to read dumped table's name from file  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: possibility to read dumped table's name from file
List 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


Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_class.reltuples of brin indexes
Next
From: Nathan Bossart
Date:
Subject: common signal handler protection