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. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs