From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Surafel Temesgen <surafel3000(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: possibility to read dumped table's name from file |
Date: | 2021-09-13 13:11:52 |
Message-ID: | 20210913131152.GO26465@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 28, 2021 at 09:28:17AM +0200, Pavel Stehule wrote:
> Here is an updated implementation of filter's file, that implements syntax
> proposed by you.
Thanks.
If there's any traction for this approach. I have some comments for the next
revision,
> +++ b/doc/src/sgml/ref/pg_dump.sgml
> @@ -789,6 +789,56 @@ PostgreSQL documentation
> </listitem>
> </varlistentry>
>
> + <varlistentry>
> + <term><option>--filter=<replaceable class="parameter">filename</replaceable></option></term>
> + <listitem>
> + <para>
> + Read objects filters from the specified file.
> + If you use "-" as a filename, the filters are read from stdin.
Say 'Specify "-" to read from stdin'
> + The lines starting with symbol <literal>#</literal> are ignored.
Remove "The" and "symbol"
> + Previous white chars (spaces, tabs) are not allowed. These
Preceding whitespace characters...
But actually, they are allowed? But if it needs to be explained, maybe they
shouldn't be - I don't see the utility of it.
> +static bool
> +isblank_line(const char *line)
> +{
> + while (*line)
> + {
> + if (!isblank(*line++))
> + return false;
> + }
> +
> + return true;
> +}
I don't think this requires nor justifies having a separate function.
Either don't support blank lines, or use get_keyword() with size==0 for that ?
> + /* Now we expect sequence of two keywords */
> + if (keyword && is_keyword(keyword, size, "include"))
> + is_include = true;
> + else if (keyword && is_keyword(keyword, size, "exclude"))
> + is_include = false;
> + else
I think this should first check "if keyword == NULL".
That could give a more specific error message like "no keyword found",
> + exit_invalid_filter_format(fp,
> + filename,
> + "expected keyword \"include\" or \"exclude\"",
> + line.data,
> + lineno);
..and then this one can say "invalid keyword".
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-09-13 13:20:37 | Re: pg_upgrade test for binary compatibility of core data types |
Previous Message | Amul Sul | 2021-09-13 13:09:13 | Re: TAP test for recovery_end_command |