Skip site navigation (1) Skip section navigation (2)

Re: Policy on pulling in code from other projects?

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-07-22 20:35:43
Subject: Re: Deferred partial/expression unique constraints
Previous:From: Peter EisentrautDate: 2011-07-22 20:08:48
Subject: Re: cataloguing NOT NULL constraints

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group