> On 4 Mar 2020, at 12:25, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> 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?
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
