Prev: Stefan's bug (was: max_standby_delay considered harmful)
Next: How to know killed by pg_terminate_backend
From: Bruce Momjian on 13 May 2010 13:14
Tom Lane wrote:
> Magnus Hagander <magnus(a)hagander.net> writes:
> > On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian <bruce(a)momjian.us> wrote:
> >> I have added SGML comments to comment out the text that mentions EDB
> >> Advanced Server. �Is that enough? �Should I remove the text from the
> >> SGML? �Should I move it to the bottom of the SGML? �Should I remove the
> >> EnterpriseDB Advanced Server checks from the C code too? �I don't
> >> remember having to deal with anything like this before, so I am unclear
> >> how to proceed.
>
> > I say remove it. On all accounts.
>
> > There's a fork of postgres for EDB AS, shouldn't there be a fork of
> > pg_upgrade the same way, if it requires special code? The code in
> > community postgresql certainly shouldn't have any EDB AS code in it.
>
> Indeed. Given the (presumably large) delta between EDB's code and ours,
> having to have some delta in pg_upgrade isn't going to make much
> difference for them. I think the community code and docs should
> completely omit any mention of that.

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.

I guess another question is whether we would accept a patch that was
useful only for a Greenplum build? And does removing such code use the
same criteria?

I know pgAdmin supports Greenplum, but that is an external tool so it
makes more sense there.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Joshua D. Drake" on 13 May 2010 13:17
On Thu, 2010-05-13 at 17:19 +0200, Magnus Hagander wrote:

> I say remove it. On all accounts.
>
> There's a fork of postgres for EDB AS, shouldn't there be a fork of
> pg_upgrade the same way, if it requires special code? The code in
> community postgresql certainly shouldn't have any EDB AS code in it.

If the code would be useful for other "projects" then keep it. If it is
only for a closed source product, dump it.

Joshua D. Drake


--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on 13 May 2010 13:32


Bruce Momjian wrote:
>> Indeed. Given the (presumably large) delta between EDB's code and ours,
>> having to have some delta in pg_upgrade isn't going to make much
>> difference for them. I think the community code and docs should
>> completely omit any mention of that.
>>
>
> 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.
>
> I guess another question is whether we would accept a patch that was
> useful only for a Greenplum build? And does removing such code use the
> same criteria?
>
> I know pgAdmin supports Greenplum, but that is an external tool so it
> makes more sense there.
>
>

What if several vendors want the same thing? The code will quickly
become spaghetti.

AFAIK the Linux kernel expects distros to keep their patchsets
separately, and I rather think we should too.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Josh Berkus on 13 May 2010 14:25
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.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Bruce Momjian on 13 May 2010 18:50
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(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Stefan's bug (was: max_standby_delay considered harmful)
Next: How to know killed by pg_terminate_backend