Обсуждение: pg_dump include/exclude fails to error
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
> 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
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 │
└────────┴──────┴───────┴───────┘
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$
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"
pg_dump: error: no matching tables were found for pattern "boo"
Regards
Pavel
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
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/