Tom Lane wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
