Re: libpq parameter parsing problem

On Tue, Jan 14, 2020 at 08:54:41PM -0700, David G. Johnston wrote:
> My rationale is more since none of the other options have structural parts
> that require escaping, and rarely do the values themselves require
> escaping, that tossing that single example for a seldom-used option into
> the middle of the "usage examples" section doesn't really fit. What the
> example does is clarify a specific combination of factors, URI and
> "options", that require special attention. I'd rather bury that special
> case in the documentation for options then explain it in detail in the
> generic URI section - the structural elements involved are already
> mentioned in the options section and this just clarifies how they are
> written in the URI situation. Its not a strong opinion but I don't think
> adding it there while leaving the other common compound usage examples as a
> whole above is a misplacement - "options" is special and can very well have
> special treatment. It will be found by those that need to know about it.

Fair point. Now, replacing a special character applies to more than
"options", because it can be used for any values. For example:
postgresql:///mydb?host=localhost&application_name=hoge%20%3D%20foo
(This generates "hoge = foo" as application_name as you can guess.)

And the part of the docs for connection URIs describes only how to
percent-encode a path.
--
Michael