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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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