Re: PATCH: Add uri percent-encoding for binary data

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Anders Åstrand <anders(at)449(dot)se>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: Add uri percent-encoding for binary data
Date: 2020-03-19 07:55:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 4 Mar 2020, at 12:25, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>> On 20 Feb 2020, at 23:27, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
>>> (
>> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-03-19 08:05:32 Re: adding partitioned tables to publications
Previous Message Daniel Gustafsson 2020-03-19 07:48:58 Re: Cache lookup errors with functions manipulation object addresses