"Greg Sabino Mullane" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
