Re: proposal: possibility to read dumped table's name from file

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: possibility to read dumped table's name from file
Дата
Msg-id CAFj8pRBq9X=oSNbo+v93EwznkQ3JczEW6UsfQK37vx1ktW-2ZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: possibility to read dumped table's name from file  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: possibility to read dumped table's name from file
Re: proposal: possibility to read dumped table's name from file
Список pgsql-hackers
Hi

út 13. 7. 2021 v 1:16 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> [1] your proposal of "[+-] OBJTYPE OBJIDENT" plus empty lines allowed
>     plus lines starting with # are comments, seems plenty.  Any line not
>     following that format would cause an error to be thrown.

I'd like to see some kind of keyword on each line, so that we could extend
the command set by adding new keywords.  As this stands, I fear we'd end
up using random punctuation characters in place of [+-], which seems
pretty horrid from a readability standpoint.

I think that this file format should be designed with an eye to allowing
every, or at least most, pg_dump options to be written in the file rather
than on the command line.  I don't say we have to *implement* that right
now; but if the format spec is incapable of being extended to meet
requests like that one, I think we'll regret it.  This line of thought
suggests that the initial commands ought to match the existing
include/exclude switches, at least approximately.

Hence I suggest

        include table PATTERN
        exclude table PATTERN

which ends up being the above but with words not [+-].

Here is an updated implementation of filter's file, that implements syntax proposed by you.

Regards

Pavel

 
                        regards, tom lane
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yugo NAGATA
Дата:
Сообщение: Re: Fix around conn_duration in pgbench
Следующее
От: Richard Guo
Дата:
Сообщение: Problem about postponing gathering partial paths for topmost scan/join rel