Re: FK's to refer to rows in inheritance child
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Dimitri Fontaine <dimitri@2ndQuadrant.fr>, Greg Stark <gsstark@mit.edu>, YebHavinga <yebhavinga@gmail.com>, PostgreSQL-development Hackers <pgsql-hackers@postgresql.org>, "w.p.dijkstra@mgrid.net" <w.p.dijkstra@mgrid.net>
Date: 2010-12-05T17:41:20Z
Lists: pgsql-hackers
On 12/05/2010 12:10 PM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> On 12/04/2010 07:12 PM, Robert Haas wrote: >>> I wouldn't necessarily be opposed to official topic branches at some point in the future, but I think it's premature to speculate about whether it'd be useful here. >> I'd need a lot of convincing if it imposed an extra burden on people >> like Tom. The only way I could see working is if some committer took >> ownership of the topic branch and guaranteed to keep it pretty much in >> sync with the master branch. > Well, allegedly this is one of the reasons we moved to git. Anybody can > do that in their own repository, just as easily as a core committer > could. AFAICS it's not necessary for the core repo to contain the > branch, up until the point where it's ready to merge into master. > Well, ISTM that amounts to not having "official topic branches" :-) I agree that this is supposed to be one of git's strengths (or more exactly a strength of distributed SCM's generally). I don't really see any great value in sanctifying a particular topic branch with some official status. What I would like to see is people publishing the location of development repos so that they can be pulled from or merged, especially for any large patch. cheers andrew