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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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