On 6 April 2012 01:19, Noah Misch <noah@leadboat.com> wrote:
> On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote:
>> On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea
>> > but I'm not convinced that all the corner-case details have been
>> > adequately thought through, and I'm scared of being unable to fix any
>> > such bugs in later versions because of backwards compatibility worries.
>> > It'd be a lot better to be pushing this in at the start of a devel cycle
>> > than the end.
>>
>> I've been feeling that that patch has been suffering from a lack of
>> reviewer attention, which is a real shame, because I think the
>> functionality is indeed really cool. But I haven't looked at it
>> enough to know what kind of shape it's in.
>
> As the reviewer, I'm not aware of any unexplored corner cases or problems that
> ought to preclude commit. That said, it is a large patch; I doubt anyone
> could pick it up from scratch and commit it with less than a solid day's
> effort, and 2-3 days might be more likely. In retrospect, I should have
> suggested splitting the new ON DELETE/ON UPDATE actions into their own patch.
> That would have nicely slimmed the base patch and also isolated it from the ON
> DELETE EACH CASCADE judgement call.
As a likely user of this feature (not sure if this needs a
"disclaimer", but my employer offered a small bounty towards the
development), I'd only need "ON DELETE RESTRICT" behaviour, currently,
and wouldn't ever need "ON UPDATE ..." as the referent column would
always be a SERIAL. In the meantime, I'm pretty sure the restriction
could be handled by a hand-rolled trigger on insert and delete, but
the delete one would be a lot slower without some kind of indexing.
