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--