> > > * Check to see if the child row exists (no action)
> > > * Delete the child row (cascade delete)
> > > * Update the child row (cascade update)
> > >
> > > All of which will benefit from an index...
> >
> > OK, then perhaps we should be creating an index automatically? Folks?
>
> The index is only useful where you actually have an on delete or on update
> clause.
Hmm...not necessarily true. A default 'no action' foreign key still needs
to prevent the parent key from being deleted if the child exists. This
requires that postgres do a search of the child table.
> I don't think we want to conditionally create an index. That would
> bee too confusing. A contrib, to find "suggested" indexes seems fine.
That's what I suggested.
Chris