Hi,
I started looking at the patch allowing to export just functions [1],
and I got pointed to this patch as an alternative approach (to adding a
separate filtering option for every possible object type).
I'm familiar with the customer that inspired Pavel to start working on
this, so I understand the use case he's trying to address - a flexible
way to filter (include/exclude) large number of objects.
IMHO it's a mistake to try to broaden the scope of the patch and require
implementing some universal pg_dump config file, particularly if it
requires "complex" structure or formats like JSON, TOML or whatever.
Maybe that's worth doing, but in my mind it's orthogonal to what this
patch aims (or aimed) to do - filtering objects using rules in a file,
not on the command line.
I believe it's much closer to .gitignore or rsync --filter than to a
full config file. Even if we end up implementing the pg_dump config
file, it'd be nice to keep the filter rules in a separate file and just
reference that file from the config file.
That also means I find it pointless to use an "advanced" format like
JSON or TOML - I think the format should be as simple as possible. Yes,
it has to support all valid identifiers, comments and so on. But I don't
quite see a point in using JSON or similar "full" format. If a simple
format is good enough for rsync or gitignore, why should we insist on
using something more complex?
OTOH I don't quite like the current approach of simply reading options
from a file, because that requires adding new command-line options for
each type of object we want to support. Which seems to contradict the
idea of "general filter" method as mentioned in [1].
So if it was up to me, I'd go back to the original format or something
close it. So something like this:
[+-] OBJECT_TYPE_PATTERN OBJECT_NAME_PATTERN
regards
[1] https://commitfest.postgresql.org/33/3051/
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company