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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Greg Stark <gsstark(at)mit(dot)edu>, YebHavinga <yebhavinga(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, "w(dot)p(dot)dijkstra(at)mgrid(dot)net" <w(dot)p(dot)dijkstra(at)mgrid(dot)net>
Subject: Re: FK's to refer to rows in inheritance child
Date: 2010-12-05 17:10:57
Message-ID: 26499.1291569057@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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.

>> What is needed right now is design work, not code.

> Indeed. In this case I don't think we even have agreement on the
> features let alone how they might work.

Yeah. But it's fair to look ahead to how development might proceed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-05 17:13:32 Re: serializable read only deferrable
Previous Message Tom Lane 2010-12-05 17:07:15 Re: Using different semaphore for locking