Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards
От | Tom Lane |
---|---|
Тема | Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards |
Дата | |
Msg-id | 22250.1137537804@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards ("Greg Sabino Mullane" <greg@turnstep.com>) |
Ответы |
Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards
Re: New pg_dump options: exclude tables/schemas, multiple |
Список | pgsql-patches |
"Greg Sabino Mullane" <greg@turnstep.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
В списке pgsql-patches по дате отправления: