Re: pg_upgrade code questions

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, Devrim GÜNDÜZ <devrim@gunduz.org>, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-05-13T17:32:48Z
Lists: pgsql-hackers

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