Re: Policy on pulling in code from other projects?

On 07/22/2011 10:57 AM, Robert Haas wrote:
> On Fri, Jul 22, 2011 at 1:26 PM, Joshua D. Drake<jd@commandprompt.com>  wrote:
>>> IMHO, it seems like it would be simpler to do that by rolling our own
>>> code rather than importing someone else's.

> I mean, look, there is precedent for doing this.  We sucked in chunks
> of snowball for tsearch and, separately, somebody's regex
> implementation.  We depend on libedit or libreadline for command-line
> editing, libssl for encryption, and various other libraries for LDAP
> and Kerberos.  So if you're asking: would we ever consider doing this?
>   Sure, because we already have.  There is no rule against it.  But if
> you're arguing that the benefits of this library for this feature are
> sufficient to justify sucking it in, I'm so far unconvinced.  What
> does it do that is so much better than what we could code up on our
> own in a couple of hours?
>

I am not neccessarily looking to include it in our tarball. What I asked 
was:

Assuming the code actually makes this patch easier, do we:

A. Pull in the code into the main tree
B. Instead have it as a requirement via configure?

I am not arguing one way or the other. I am trying to find the best 
solution. I personally think you are handwaving if you think we can 
build out a robust parser in a couple of hours.

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? (I am not being sarcastic), 
if we don't let's just throw some simple code together, if we do, I 
think this library makes sense, whether in our tree or not.

Sincerely,

Joshua D. Drake

-- 
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579