On 07/22/2011 10:57 AM, Robert Haas wrote:
On Fri, Jul 22, 2011 at 1:26 PM, Joshua D. Drake<j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
