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

Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards
Date: 2006-01-17 22:43:24
Message-ID: 22250.1137537804@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
> 2) It would be a lot more work to send it to the backend or import some
> of the regex code.

Importing regex code into pg_dump certainly sounds like a loser.
However, it doesn't seem to me that it'd be that hard to issue
commands like
	select relname from pg_class where relname like <pattern>
then save aside this list to match against stuff-to-dump.

> 3) It would require yet more arguments to pg_dump. The moment we start allowing
> regular expression characters that are also valid identifier names (e.g. "."
> and "_") we'll need some way to tell pg_dump whether we mean a literal search
> or a regular expression one.

However, we are going to have that problem in spades if we do a
half-baked pattern feature now and then want to improve it later.
I think it'd be better to get it right the first time.

In practice, I don't think that LIKE-style patterns (% and _ wildcards)
will pose a serious compatibility problem if we just decree that the
-n and -t switches now take patterns rather than plain names.  I agree
that regex-style patterns would open some gotchas, but what's wrong with
standardizing on LIKE patterns?

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-01-18 00:51:05
Subject: Re: Huge number of disk writes after migration to 8.1
Previous:From: Greg Sabino MullaneDate: 2006-01-17 22:26:58
Subject: Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards

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