Re: libpq parameter parsing problem - Mailing list pgsql-bugs

From Oleksandr Shulgin
Subject Re: libpq parameter parsing problem
Date
Msg-id CACACo5RmzPraKgrpcQrWLC782ViHF06NOScBLYnj5WqhcY2WwA@mail.gmail.com
Whole thread Raw
In response to Re: libpq parameter parsing problem  (Michael Paquier <michael@paquier.xyz>)
Responses Re: libpq parameter parsing problem
List pgsql-bugs
On Thu, Jan 16, 2020 at 4:49 AM Michael Paquier <michael@paquier.xyz> wrote:

> Links to authoritative sources (perhaps an RFC in this case) would be
> better.

No objections to your suggestion in this case though.  I can see
Section 2.1 from RFC3986 for that:
https://tools.ietf.org/html/rfc3986#section-2.1

Yes, this makes more sense, especially since we already refer to that same RFC earlier on the page:

> URIs generally follow <ulink url="https://tools.ietf.org/html/rfc3986">RFC 3986</ulink>,...

For a moment I thought we could improve further if we rephrase "symbols with special meaning" as "reserved characters", which are defined in section 2.2 of the RFC.  But that set is broader than what actually needs to be encoded for correct interpretation by our parser.

At the same time, we could still be more specific if we would say "delimiters" instead of the generic "special meaning".  Should we then provide an exhaustive list of delimiters or is it clear enough like that?  For example, the whitespace doesn't need to be percent-encoded (it doesn't hurt as you might be able to spare the quoting if using it as an argument to a shell command), while the "equal sign", when used in the query string part, does need encoding.

--
Alex

pgsql-bugs by date:

Previous
From: Jobin Augustine
Date:
Subject: Re: libpq parameter parsing problem
Next
From: PG Bug reporting form
Date:
Subject: BUG #16208: background worker "logical replication worker" was terminated by signal 11: Segmentation