From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Policy on pulling in code from other projects? |
Date: | 2011-07-22 20:25:34 |
Message-ID: | 4E29DCBE.3050406@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/22/2011 02:09 PM, Joshua D. Drake wrote:
> Remember this library follows the RFC for URIs which is why I even
> brought it up. If it was just some random parser, I wouldn't even have
> bothered. Do we care about the RFC for URIs?
The main components of the RFC involve:
-Decoding escaped characters entered by percent-encoding
-Parsing the permissible IPv4 and IPv6 addresses
-Handling absolute vs. relative addresses. This is a lot of the spec,
and it's not really relevant for PostgreSQL URIs
-Splitting the URI into its five main components
I know I've seen a URL-oriented %-encoding decoder as a PostgreSQL
function already (I think Gabriele here wrote one). Surely useful IP
address decoding functions are already around. And the splitting part
seems like a fairly straightforward bit of regular expression work.
I think one crossover point where it's absolutely worth using the
external library for this purpose is if you have an app that has to
follow all of the rules around path names. If this project didn't
already have libraries around for things like IP address parsing, using
the library instead would also make more sense. The remaining chores if
you don't worry about all the path name trivia, and know how to
interpret an IP address, seem feasible to do directly.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-07-22 20:35:43 | Re: Deferred partial/expression unique constraints |
Previous Message | Peter Eisentraut | 2011-07-22 20:08:48 | Re: cataloguing NOT NULL constraints |