Greetings, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > I agree that being able to configure pg_dump via a config file would > > be very useful, but the syntax proposed here feels much more like a > > hacked-up syntax designed to meet this one use case, rather than a > > good general-purpose design that can be easily extended. > > Nobody sent a real use case for introducing the config file. There was a > discussion about formats, and you introduce other dimensions and > variability.
I'm a bit baffled by this because it seems abundently clear to me that being able to have a config file for pg_dump would be extremely helpful. There's no shortage of times that I've had to hack up a shell script and figure out quoting and set up the right set of options for pg_dump, resulting in things like: pg_dump \ --host=myserver.com \ --username=postgres \ --schema=public \ --schema=myschema \ --no-comments \ --no-tablespaces \ --file=somedir \ --format=d \ --jobs=5 which really is pretty grotty. Being able to have a config file that has proper comments would be much better and we could start to extend to things like "please export schema A to directory A, schema B to directory B" and other ways of selecting source and destination, and imagine if we could validate it too, eg: pg_dump --config=whatever --dry-run or --check-config maybe. This isn't a new concept either- export and import tools for other databases have similar support, eg: Oracle's imp/exp tool, mysqldump (see: https://dev.mysql.com/doc/refman/8.0/en/option-files.html which has a TOML-looking format too), pgloader of course has a config file, etc. We certainly aren't in novel territory here. Thanks, Stephen
signature.asc
Description: PGP signature