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