> On 20 Feb 2020, at 23:27, Alvaro Herrera <alvherre@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
