pg_dump include/exclude fails to error

Started by Magnus Haganderalmost 2 years ago4 messages
#1Magnus Hagander
magnus@hagander.net

When including tables with the new pg_dump functionality, it fails to
error out if a table is missing, but only if more than one table is
specified.

E.g., if table foo exist, but not bar:

pg_dump --table bar
pg_dump: error: no matching tables were found

with file "myfilter" containing just "table bar"
pg_dump --filter myfilter
pg_dump: error: no matching tables were found

with the file "myfilter" containing both "table foo" and "table bar"
(order doesn't matter):
<no error, but dump of course only contains foo>

Not having looked into the code, but it looks to me like some variable
isn't properly reset, or perhaps there is a check for existence rather
than count?

//Magnus

#2Daniel Gustafsson
daniel@yesql.se
In reply to: Magnus Hagander (#1)
Re: pg_dump include/exclude fails to error

On 10 Mar 2024, at 15:22, Magnus Hagander <magnus@hagander.net> wrote:

Not having looked into the code, but it looks to me like some variable
isn't properly reset, or perhaps there is a check for existence rather
than count?

Thanks for the report, I'll have a look later today when back.

--
Daniel Gustafsson

#3Pavel Stehule
pavel.stehule@gmail.com
In reply to: Magnus Hagander (#1)
Re: pg_dump include/exclude fails to error

Hi

ne 10. 3. 2024 v 15:23 odesílatel Magnus Hagander <magnus@hagander.net>
napsal:

When including tables with the new pg_dump functionality, it fails to
error out if a table is missing, but only if more than one table is
specified.

E.g., if table foo exist, but not bar:

pg_dump --table bar
pg_dump: error: no matching tables were found

with file "myfilter" containing just "table bar"
pg_dump --filter myfilter
pg_dump: error: no matching tables were found

with the file "myfilter" containing both "table foo" and "table bar"
(order doesn't matter):
<no error, but dump of course only contains foo>

is not this expected behaviour (consistent with -t option)?

(2024-03-10 16:48:07) postgres=# \dt
List of relations
┌────────┬──────┬───────┬───────┐
│ Schema │ Name │ Type │ Owner │
╞════════╪══════╪═══════╪═══════╡
│ public │ foo │ table │ pavel │
└────────┴──────┴───────┴───────┘
(1 row)

pavel@nemesis:~/src/orafce$ /usr/local/pgsql/master/bin/pg_dump -t foo -t
boo > /dev/null
pavel@nemesis:~/src/orafce$

if you want to raise error, you should to use option --strict-names.

pavel@nemesis:~/src/orafce$ /usr/local/pgsql/master/bin/pg_dump -t foo -t
boo --strict-names > /dev/null
pg_dump: error: no matching tables were found for pattern "boo"

Regards

Pavel

Show quoted text

Not having looked into the code, but it looks to me like some variable
isn't properly reset, or perhaps there is a check for existence rather
than count?

//Magnus

#4Magnus Hagander
magnus@hagander.net
In reply to: Pavel Stehule (#3)
Re: pg_dump include/exclude fails to error

On Sun, Mar 10, 2024 at 4:51 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:

Hi

ne 10. 3. 2024 v 15:23 odesílatel Magnus Hagander <magnus@hagander.net> napsal:

When including tables with the new pg_dump functionality, it fails to
error out if a table is missing, but only if more than one table is
specified.

E.g., if table foo exist, but not bar:

pg_dump --table bar
pg_dump: error: no matching tables were found

with file "myfilter" containing just "table bar"
pg_dump --filter myfilter
pg_dump: error: no matching tables were found

with the file "myfilter" containing both "table foo" and "table bar"
(order doesn't matter):
<no error, but dump of course only contains foo>

is not this expected behaviour (consistent with -t option)?

(2024-03-10 16:48:07) postgres=# \dt
List of relations
┌────────┬──────┬───────┬───────┐
│ Schema │ Name │ Type │ Owner │
╞════════╪══════╪═══════╪═══════╡
│ public │ foo │ table │ pavel │
└────────┴──────┴───────┴───────┘
(1 row)

pavel@nemesis:~/src/orafce$ /usr/local/pgsql/master/bin/pg_dump -t foo -t boo > /dev/null
pavel@nemesis:~/src/orafce$

if you want to raise error, you should to use option --strict-names.

pavel@nemesis:~/src/orafce$ /usr/local/pgsql/master/bin/pg_dump -t foo -t boo --strict-names > /dev/null
pg_dump: error: no matching tables were found for pattern "boo"

Hmpf, you're right. I guess I don't use multiple-dash-t often enough
:) So yeah, then I agree this is probably the right behaviour. Maybe
the docs for --filter deserves a specific mention about these rules
though, as it's going to be a lot more common to specify multiples
when using --filter?

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/