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