On Fri, Jan 21, 2022 at 5:42 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > The point I was trying to make is that if we have to jump through > that sort of hoop in the test scripts, then real users are going > to have to jump through it as well, and they won't like that > (and we will get bug reports about it). It'd be better to design > the option syntax to avoid such requirements.
Well, as Andrew points out, pg_basebackup's -T foo=bar syntax causes the same issue, so you'll need to redesign that, too. But even that is not really a proper fix. The real root of this problem is that the operating system's notion of a valid path differs from PostgreSQL's notion of a valid path on this platform, and I imagine that fixing that is a rather large project. ISTM that you're basically just complaining about options syntax that you don't like, but I think there's nothing particularly worse about this syntax than lots of other things we type all the time. psql -v VAR=VALUE -P OTHERKINDOFVAR=OTHERVALUE? curl -u USER:PASSWORD? pg_basebackup -T OLD=NEW? perl -d[t]:MODULE=OPT,OPT? I mean, that last one actually seems kinda horrible and if this were as bad as that I'd say yeah, it should be redesigned. But I don't think it is. There's plenty of precedent for bundling closely-related values into a single command-line option, which is all I've done here. -- Robert Haas EDB: http://www.enterprisedb.com
