Re: libpq parameter parsing problem

Michael Paquier <[email protected]> Wed, 15 Jan 2020 14:14:18 +0900
Newsgroups gmane.comp.db.postgresql.bugs
Message-ID <[email protected]>
--m+jEI8cDoTn6Mu9E
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--m+jEI8cDoTn6Mu9E
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl4en6oACgkQnvQgOdby
QH1oyw//bG5jxM05mc7VR2zJXIBwDgwH9TCEoG1QK3xYtaHsJcWRC6DHkkL5hjj7
N/OwUc7orQzyru47XNPJWxi0n8rFigURU3O5xQm7TnQH8T6fuXbDlbWCl9O6Lz5s
eSaDwksJf3nB2LN7WiTiW5HkG/rq5Jo72tH4yXotpTa8a7l3dHsNx1DIjEkb+Fge
7gOFIcDz0OlA7VAS12AtqvuMNFqm56pIZPwY+mIhgr+Jp+tZ5ZLPZwM6Sso0Pdew
OJampSJQhxjxAdKG7E/9gBUtjwsZ6UaoFjGJOvpV5mTWmy88bEtN8PyS6kb3eJc4
Qz3MJzTGRf+CX8Tw9P2PEpdr1FHq/LhhASeLr0iBAOaE+38IxMO6+Iw7qY+ifCMr
FHOgM2LQrTGtZTDl+WlAvGmXrhsLhydkU7H6t3TjjMgBUjBcoYod1xSDT6fnRaFZ
VYPBe93Sg7muen30m9Y2Bw6qj+DTEPEOKe/gv6cXN7KloYH7yjAneR9c6Xztq1na
0OHYc2Ru8Ckzwiu4ysH0+SNLR5Xchl0i0tpxhkt6DpDpB1b42+3U5bfkeuXYLiq9
zxzaVqRg/gxWxUQZYwNzyA8iKwrFCVZ1EhsI50W3oCjIdR+5+2v0qmTTrRXXqIGj
Up1Pv8Xv6F4ajB6U89C6ddYD2F/HpoD7jhK0nml4k/3g9qUj+aU=
=jRHE
-----END PGP SIGNATURE-----

--m+jEI8cDoTn6Mu9E--