> 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? cheers ./daniel