Re: proposal: possibility to read dumped table's name from file - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: proposal: possibility to read dumped table's name from file |
| Date | |
| Msg-id | CAFj8pRC6XnB8hRiyEQp4jrGReMQy-hcAWwLMVFS=ztZP-pPU0Q@mail.gmail.com Whole thread Raw |
| In response to | Re: proposal: possibility to read dumped table's name from file (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| List | pgsql-hackers |
st 11. 11. 2020 v 16:17 odesílatel Alvaro Herrera <alvherre@alvh.no-ip.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
pgsql-hackers by date: