On Tue, Jul 5, 2011 at 12:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> The code that recognizes a default expression as being just constant >>> NULL doesn't think this is a constant NULL. In principle it could >>> recognize that, since the cast function is marked strict, but so far >>> it has not seemed worth the trouble. > >> Gee, does Noah's recent patch adding the notion of "transform >> functions" have any applicability to this problem? > > Not really. If someone held a gun to my head and said "fix that", what > I'd do is run eval_const_expressions() on the default expression and see > if that resulted in a constant NULL. But it seems unlikely to be worth > the cycles in most cases. Also, we'd then need some other test to > address the issue explained in AddRelationNewConstraints: > > /* > * If the expression is just a NULL constant, we do not bother to make > * an explicit pg_attrdef entry, since the default behavior is > * equivalent. > * > * Note a nonobvious property of this test: if the column is of a > * domain type, what we'll get is not a bare null Const but a > * CoerceToDomain expr, so we will not discard the default. This is > * critical because the column default needs to be retained to > * override any default that the domain might have. > */ > if (expr == NULL || > (IsA(expr, Const) &&((Const *) expr)->constisnull)) > continue; > > IOW, there are cases where "DEFAULT NULL" is *not* a no-op.
Interesting. A possible reason to care about this is that it might convert a form of ALTER TABLE that requires a rewrite into one that doesn't, since we needn't rewrite the table if the column will be all-nulls. That's not enough of a benefit to motivate me to do the work myself, since all the examples thus-far shown involve writing the default in a way that's more complicated than necessary. But I'd have a hard time objecting if someone else wanted to run it down, since I'm pretty sure I've written an ALTER TABLE that way once or twice myself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
