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

On Tue, Jul 5, 2011 at 12:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

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