Hi I'm currently investigating how much work it'd be to implement arrays of domains since I have a client who might be interested in sponsoring that work.
The comments around the code handling ALTER DOMAIN ADD CONSTRAINT are pretty clear about the lack of proper locking in that code - altering a domain while simultaneously add a column with that domain as a type might result in inconsistencies between the data in that column and the domain's constraints after both transactions committed. I do, however, suspect that ALTER TABLE is plagued by similar problems. Currently, during the rewrite phase of ALTER TABLE, find_composite_type_dependencies is used to verify that the table's row type (or any type directly or indirectly depending on that type) is not used as a column's type anywhere in the database. But since this code does not take any permanent locks on the visited types, it seems that adding such a column concurrently is not prevented. If the original ALTER TABLE changed a column's type, data inserted into the newly added column before the original ALTER TABLE committed will have a type different from what the catalog says after the original ALTER TABLE commits. Or at least so I think - I haven't yet tested that theory... I am aware that since a commit fest is currently running, now might not be the best time to bring up this topic. Since I feared forgetting this all together, I decided to still post now, though. I figured people still have to option to ignore this for now if they're busy with getting those patches committed. best regards, Florian Pflug
smime.p7s
Description: S/MIME Cryptographic Signature
