Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane <tgl@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