Vitaly Burovoy <vitaly.buro...@gmail.com> writes: > But what I discover for myself is that we have pg_attrdef separately > from the pg_attribute. Why?
The core reason for that is that the default expression needs to be a separate object from the column for purposes of dependency analysis. For example, if you have a column whose default is "foo()", then the default expression depends on the function foo(), but the column should not: if you drop the function, only the default expression ought to be dropped, not the column. Because of this, the default expression needs to have its own OID (to be stored in pg_depend) and it's convenient to store it in a separate catalog so that the classoid can identify it as being a default expression rather than some other kind of object. If we were going to allow these missing_values or creation_defaults or whatever they're called to be general expressions, then they would need to have their own OIDs for dependency purposes. That would lead me to think that the best representation is to put them in their own rows in pg_attrdef, perhaps adding a boolean column to pg_attrdef to distinguish regular defaults from these things. Or maybe they even need their own catalog, depending on whether you think dependency analysis would want to distinguish them from regular defaults using just the classoid. Now, as I just pointed out in another mail, realistically we're probably going to restrict the feature to simple constants, which'd mean they will depend only on the column's type and can never need any dependencies of their own. So we could take the shortcut of just storing them in a new column in pg_attribute. But maybe that's shortsighted and we'll eventually wish we'd done them as full-fledged separate objects. But on the third hand ... once one of these is in place, how could you drop it separately from the column? That would amount to a change in the column's stored data, which is not what one would expect from dropping a separate object. So maybe it's senseless to think that these things could ever be distinct objects. But that definitely leads to the conclusion that they're constants and nothing else. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers