On 6 April 2012 01:19, Noah Misch <n...@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 <t...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
