On Thu, 26 Nov 2020 at 06:43, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > st 25. 11. 2020 v 21:00 odesÃlatel Tom Lane <t...@sss.pgh.pa.us> napsal: >> >> (One thing to consider is >> how painful will it be for people to quote table names containing >> funny characters, for instance. On the command line, we largely >> depend on the shell's quoting behavior to solve that, but we'd not >> have that infrastructure when reading from a file.) > > This is not a problem with the current patch - and the last version of this > patch supports well obscure names. >
Actually, that raises a different possible benefit of passing options in an options file -- if the user wants to pass in a table name pattern, it can be a nuisance if the shell's argument processing does additional unwanted things like globbing and environment variable substitutions. Using an options file could provide a handy way to ensure that any option values are interpreted exactly as written, without any additional mangling. > There was a requirement for supporting all and future pg_dump options - ok it > can make sense. I have not a problem to use instead a line format > > "option argument" or "long-option=argument" > > This format - can it be a solution? I'll try to rewrite the parser for this > format. > Yes, that's the sort of thing I was thinking of, to make the feature more general-purpose. > It is implementable, but this is in collision with Stephen's requirement for > human well readable format designed for handy writing. There are requests > that have no intersection. Well readable format needs a more complex parser. > And machine generating in this format needs more fork - generating flat file > is more simple and more robust than generating JSON or YAML. > To be clear, I wasn't suggesting that this patch implement multiple formats. Just the "plain" format above. Other formats like YAML might well be more human-readable, and be able to take advantage of values that are lists to avoid repeating option names, and they would have the advantage of being readable and writable by other standard tools, which might be useful. But I think such things would be for the future. Maybe no one will ever add support for other formats, or maybe someone will just write a separate external tool to convert YAML or JSON to our plain format. I don't know. But supporting all pg_dump options makes more things possible. >> I wasn't very excited about multiple switch files either, though >> depending on how the implementation is done, that could be simple >> enough to be in the might-as-well category. >> That's what I was hoping. Regards, Dean
