Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> writes:
> > I also haven't checked the constraint name. To do so it would make sense to
> > use a small hash table.
>
> No, it'd make sense to use strcmp(). It's unlikely that there will be
> enough constraints attached to any one table to justify use of any but
> the simplest algorithm. AFAICS you should just iterate through the
> child constraints looking for matches ... and I'd suggest checking the
> name first, as that will save a whole lot more work in reverse-compiling
> than any amount of tenseness in the matching code.
So should I set up a nested scan, essentially implementing a nested loop? or
should I gather together all the children in a list? My inclination is to
avoid the repeated scans and gather them together in a list of cons cells of
the two strings. Or can I stuff the whole tuple in the list elements? I'm
unclear on the memory management of tuples in the midst of a scan; would I
have to copy them?
Are the scans less expensive than I imagine and there's no point in storing
the results?
And are there any other fields of pg_constraint that I should be checking for
matches in? Do we care if a parent table has a non-deferrable constraint and
the child has a deferrable one, or if the parent's is deferred by default and
the child isn't?
> > I'm ignoring unique, primary key, and foreign key constraints on the theory
> > that these things don't really work on inherited tables yet
> > anyways.
>
> Yeah, the consistent thing to do with these is nothing, until something
> is done about the generic problem.
It seems to me that foreign key constraints ought to be copied even now
though.
Also, it seems to me that LIKE ought to copy constraints or at least have an
option to. Otherwise it's not really suitable for creating partitions which
would be sad since it seems perfect for that task.
--
greg
