Re: Policy on pulling in code from other projects?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Policy on pulling in code from other projects?
Date: 2011-07-22 17:57:46
Message-ID: CA+TgmobkYkOdT0sZYR45S0NCGwUWXgKYdoczyveHvyheddx8xw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 22, 2011 at 1:26 PM, Joshua D. Drake <jd(at)commandprompt(dot)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 guess it would depend on how full featured we want the code. The library
> provides validation of various things that rolling our own code likely
> wouldn't. I mean, it is a library just like libssl or any other such thing.

Uhm, that's a complete apples-and-oranges comparison. libssl is at
least three orders of magnitude more complicated than URL parsing, and
provides a critical feature we would otherwise lack. Parsing URLs is
trivial and something we can easily code ourselves, and supports a
marginal feature that would be nice to have but is not make-or-break.

If we decide to pull their source code into our repo, then will you
also expect us to update it every time they release a new feature?
What about when they fix a bug? What about when they fix a security
bug? And what happens when the next 15 people who want similarly
minor features want some library included to support their feature,
too? Shall we now be responsible for syncing up with all of those
projects?

> I would imagine that rolling our own code would likely be simpler but the
> code itself would be dumber (not bad, just not as capable) and we would be
> duplicating the effort of an already established project. Do we really want
> to do that?

Odds are good that most of the extra features they've added are things
we don't need or can't benefit from. AFAIK, we only care about pgsql
URLs, not http or wais or whatever other crazy things they support.
So we'll be increasing either the amount of code we have to maintain -
and the size of our binaries on disk - for basically no benefit. Do
we really want to do that?

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2011-07-22 18:09:26 Re: Policy on pulling in code from other projects?
Previous Message David E. Wheeler 2011-07-22 17:34:39 Re: pg_class.relistemp