Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: > > 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. > > Huh? Any format we might devise, or borrow, will have to have some > kind of escaping/quoting convention. The idea that "we don't need > that" tends to lead to very ugly workarounds later.
Agreed. > I do agree that the shell's quoting conventions are pretty messy > and so those aren't the ones we should borrow. We could do a lot > worse than to use some established data format like JSON or YAML. > Given that we already have src/common/jsonapi.c, it seems like > JSON would be the better choice of those two. JSON doesn't support comments, something that's really useful to have in configuration files, so I don't agree that it's a sensible thing to use in this case. JSON also isn't very forgiving, which is also unfortunate and makes for a poor choice. This is why I was suggesting TOML up-thread, which is MIT licensed, has been around for a number of years, supports comments, has sensible quoting that's easier to deal with than the shell, and has a C (C99) implementation. It's also used in quite a few other projects. In a quick look, I suspect it might also be something that could be used to replace our existing hand-hacked postgresql.conf parser and give us the ability to handle things a bit cleaner there too... Thanks, Stephen
signature.asc
Description: PGP signature
