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

st 11. 11. 2020 v 16:17 odesílatel Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
napsal:

> On 2020-Nov-11, Pavel Stehule wrote:
>
> > I think the proposed feature is very far to be the config file for
> pg_dump
> > (it implements a option "--filter"). This is not the target. It is not
> > designed for this. This is just an alternative for options like -t, -T,
> ...
> > and I am sure so nobody will generate this file manually. Main target of
> > this patch is eliminating problems with the max length of the command
> line.
> > So it is really not designed to be the config file for pg_dump.
>
> I agree that a replacement for existing command line arguments is a good
> goal, but at the same time it's good to keep in mind the request that
> more object types are supported as dumpable. While it's not necessary
> that this infrastructure supports all object types in the first cut,
> it'd be good to have it support that. I would propose that instead of a
> single letter 't' etc we support keywords, maybe similar to those
> returned by getObjectTypeDescription() (with additions -- for example
> for "table data"). Then we can extend for other object types later
> without struggling to find good letters for each.
>
> Of course we could allow abbrevations for common cases, such that "t"
> means "table".
>
> For example: it'll be useful to support selective dumping of functions,
> materialized views, foreign objects, etc.
>

Implementation of this is trivial.

The hard work is mapping pg_dump options on database objects. t -> table is
simple, but n -> schema looks a little bit inconsistent - although it is
consistent with pg_dump. d or D - there is no system object like data. I am
afraid so there are two independent systems - pg_dump options, and database
objects, and it can be hard or not very practical to join these systems.
Unfortunately there is not good consistency in the short options of pg_dump
today. More - a lot of object names are multi words with inner space. This
is not too practical.

What about supporting two syntaxes?

1. first short current +-tndf filter - but the implementation should not be
limited to one char - there can be any string until space

2. long syntax - all these pg_dump options has long options, and then we
can extend this feature without any problem in future

table|exclude-table|exclude-table-data|schema|exclude-schema|include-foreign-data=PATTERN

so the content of filter file can looks like:

+t mytable
+t tabprefix*
-t bigtable

table=mytable2
exclude-table=mytable2

This format allows quick work for most common database objects, and it is
extensible and consistent with pg_dump's long options.

What do you think about it?

Personally, I am thinking that it is over-engineering a little bit, maybe
we can implement this feature just test first string after +- symbols
(instead first char like now) - and any enhanced syntax can be implemented
in future when there will be this requirement. Second syntax can be
implemented very simply, because it can be identified by first char
processing. We can implement second syntax only too. It will work too, but
I think so short syntax is more practical for daily work (for common
options). I expect so 99% percent of this objects will be "+t tablename".

Regards

Pavel