Re: pg_upgrade code questions

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade code questions
Date: 2010-05-13 22:50:05
Message-ID: 201005132250.o4DMo5612535@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus wrote:
> On 5/13/10 10:14 AM, Bruce Momjian wrote:
> > I am trying to think of this as a non-EnterpriseDB employee. If suppose
> > Greenplum had given us a utility and they wanted it to work with their
> > version of the database, what accommodation would we make for them? I
> > agree on the documentation, but would we allow #ifdefs that were only
> > used by them if there were only a few of them? Could we treat it as an
> > operating system that none of us use? I don't think Greenplum would
> > require us to keep support for their database, but they would prefer it,
> > and it might encourage more contributions from them. Maybe we would
> > just tell them to keep their own patches, but I figured I would ask
> > specifically so we have a policy for next time.
>
> My $0.021746:
>
> If something is going to be included in /contrib, it should only include
> code which relates to standard PostgreSQL. The independant pg_migrator
> project can be a PG/EDBAS tool; the contrib module needs to be
> vanilla-postgres only. If the donor of the code wants to keep the
> specific fork support, then it should remain an independant project.
>
> I'm not just referring to EDB here, or even just proprietary forks; even
> open source forks (like PostgresXC or pgCluster) shouldn't have specific
> code in /contrib. Within the limits of reasonableness, of course.
>
> My argument isn't based on purity, but is rather based on:
> (a) avoiding confusing the users, and
> (b) avoiding bulking code with lots of ifdefs if we can avoid it, and
> (c) fork release cycles are often different from pgsql-core, and EDB's
> certainly is.

I was more interested in understanding our policy rather than how to
handle this specific issue. I have removed all mentions of EnterpriseDB
Advanced Server from pg_upgrade with the attached patch. I will keep
the patch for submission back to EnterpriseDB when they want it, or they
can just pull it from CVS.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

Attachment Content-Type Size
/rtmp/diff text/x-diff 14.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2010-05-13 22:52:46 Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Previous Message Tom Lane 2010-05-13 22:46:04 Re: List traffic