Re: pg_upgrade code questions
От | Andrew Dunstan |
---|---|
Тема | Re: pg_upgrade code questions |
Дата | |
Msg-id | 4BEC37C0.40905@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_upgrade code questions (Bruce Momjian <bruce@momjian.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: