I definitely agree that we should have two files, one for config and another one for filter, since their purposes are orthogonal and their formats are likely different; trying to cram the filter specification in the config file seems unfriendly because it'd force users to write the filter in whatever alien grammar used for the config file. Also, this would make it easier to use a single config file with a bunch of different filter files.
On 2021-Sep-21, Daniel Gustafsson wrote: > I'm not convinced that we can/should change or remove a commandline parameter > in a coming version when there might be scripts expecting it to work in a > specific way. Having a --filter as well as a --config where the configfile > can > refer to the filterfile also passed via --filter sounds like problem waiting > to > happen, so I think we need to settle how we want to interact with this file > before anything goes in. I think both the filter and the hypothetical config file are going to interact (be redundant) with almost all already existing switches, and there's no need to talk about removing anything (e.g., nobody would argue for the removal of "-t" even though that's redundant with the filter file). I see no problem with the config file specifying a filter file. AFAICS if the config file specifies a filter and the user also specifies a filter in the command line, we have two easy options: raise an error about the redundant option, or have the command line option supersede the one in the config file. The latter strikes me as the more useful behavior, and it's in line with what other tools do in similar cases, so that's what I propose doing. (There might be less easy options too, such as somehow combining the two filters, but offhand I don't see any reason why this is real-world useful, so I don't propose doing that.) -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "How amazing is that? I call it a night and come back to find that a bug has been identified and patched while I sleep." (Robert Davidson) http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php
