Tom Lane <tgl@sss.pgh.pa.us> writes:
> I don't believe those attributes mean anything for check constraints
> ATM, but you may as well compare them anyway. If we ever do implement
> them then it'd be reasonable to expect parent and child to have
> identical settings.
I'm not sure. Does it have to have identical behaviour as long as it
guarantees the same level of data integrity? Deferred constraints will still
guarantee that the promises of the parent table are met.
But in that case I guess I really have to store the whole tuple. I'll look
into the stuff you suggested I look at to do that.
> > Also, it seems to me that LIKE ought to copy constraints or at least have an
> > option to.
>
> What does the spec say about that?
It says:
NOTE 245 \u2014 <column constraint>s, except for NOT NULL, are not
included in CDi; <column constraint definition>s are effectively
transformed to <table constraint definition>s and are thereby also
excluded.
We could still do an INCLUDING CONSTRAINTS option or something like that?
It seems it would make it much more convenient for creating partitions. Then
we could document that "CREATE TABLE child (LIKE parent INCLUDING
CONSTRAINTS)" is guaranteed to create a suitable child table for your parent
table.
--
greg