Skip site navigation (1) Skip section navigation (2)

Re: pgdump

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Andreas Joseph Krogh <andreak(at)officenet(dot)no>,Enrico <scotty(at)linuxtime(dot)it>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgdump
Date: 2005-01-17 06:46:39
Message-ID: 1105944399.22946.74.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote:
> Just to be clear: what I understand the logic to be is "OR" across
> multiple switches of the same type, but "AND" across switches of
> two types.

If I understand you correctly, you're suggesting that we should only
report an error if none of the specified tables exist OR none of the
specified schemas exist. I'm not sure I agree. Consider this command:

pg_dump -t some_table -t non_existent_table

Assuming some_table exists, we will now blithely ignore the nonexistent
table. That is perfectly reasonable because of the cartesian explosion
of possibilities that occurs when both -t and -n are specified, but in
the absence of that it seems regrettable. The same applies to "-n foo -n
non_existent_schema", naturally.

An easy fix would be to raise an error for each specified but
nonexistent object, *except* if both "-n" and "-t" are specified, in
which case we use your behavior (report an error if none of the
specified tables are found OR none of the specified schemas are found).
Perhaps better would be to require that each "-t" or "-n" switch results
in a 'match' -- i.e. if you specify "-t foo -n x -n y", we check that

(a) schema x exists AND
(b) schema y exists AND
(c) table foo exists in (schema x OR schema y)

This means we have tighter error checking, although I'm not sure how
intuitive it is.

-Neil



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-17 07:40:19
Subject: Re: pgdump
Previous:From: Tom LaneDate: 2005-01-17 06:19:36
Subject: Re: pgdump

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group