Re: FK's to refer to rows in inheritance child

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Topic branches defined that way seem like a pretty bad idea from here.
> They would save no effort at all for committers, because if you're not
> allowed to object to something after it's gone into a topic branch, then
> it's just like master in terms of having to keep up with changes as they
> happen. Moreover, we'd have to keep them in pretty close sync with
> master --- otherwise what happens when you discover that some long-ago
> change on master breaks the topic branch? So AFAICS this would just
> increase the amount of keeping-branches-in-sync dogwork without any
> offsetting advantage.

The only advantage I can think about is twofold:
- publish what feature set you want to have complete to consider merge
- have more than one person able to partake into making it happen

Maybe it's just me, but it seems like some people sent in patches to
solve a partial set of the partitioning-for-real work and those have
been rejected on the grounds that it's not complete. This topic
branches idea is all about being able to review and apply the patches,
and say "we still need this and that stuff to get done someday before we
consider a merge".

Do you prefer this all to happen externally and without commiters
helping in the incremental effort? I can see the burden if we include
such topic branch in our existing processes, but also the advantages.
You call that a judgement call, right? It's surely not mine to make.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr