Re: Policy on pulling in code from other projects?
От | Greg Smith |
---|---|
Тема | Re: Policy on pulling in code from other projects? |
Дата | |
Msg-id | 4E29DCBE.3050406@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Policy on pulling in code from other projects? ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: Policy on pulling in code from other projects?
|
Список | 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@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
В списке pgsql-hackers по дате отправления: