Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org