> On 4 Mar 2020, at 12:25, Daniel Gustafsson <dan...@yesql.se> wrote: > >> On 20 Feb 2020, at 23:27, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >> >> On 2019-Oct-07, Anders Åstrand wrote: >> >>> Attached is a patch for adding uri as an encoding option for >>> encode/decode. It uses what's called "percent-encoding" in rfc3986 >>> (https://tools.ietf.org/html/rfc3986#section-2.1). >> >> Thanks. Seems useful. I made a few cosmetic tweaks and it looks almost >> ready to me; > > I agree that uri decoding/encoding would be useful, but I'm not convinced that > this patch does the functionality justice enough to be useful. What is the > usecase we envision to solve when not taking scheme into consideration? > > Reserved characters have different meaning based on context and scheme, and > should not be encoded when used as a delimiter. This does make the patch a > lot > more complicated, but if we provide a uri encoding which percent-encode the > delimiters in https:// I would expect that to be reported to pgsql-bugs@ > repeatedly. Adding URIs with userinfo makes it even more problematic, as > encoding the @ delimiter will break it. > > Further, RFC6874 specifies that ipv6 URIs with zone identifiers are written > as: > IPv6address "%25" ZoneID. With this patch it would be encoded %2525 ZoneID > which is incorrect. > > That being said, if we do look at the scheme then we'll need to decide which > URI standard we want to stick to as RFC3986 and WHATWG URL-spec aren't > compatible. > > Perhaps not calling it 'uri' and instead renaming it to 'percent-encoding' can > make it clearer, while sticking to the proposed feature?
With no response for 2 weeks during the commitfest, I propose to move this to the next CF to allow time for discussions. cheers ./daniel
