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
