Skip site navigation (1) Skip section navigation (2)

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chris Bandy <bandy(dot)chris(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Date: 2011-07-05 16:52:16
Message-ID: (view raw or whole thread)
Lists: pgsql-bugs
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
The Enterprise PostgreSQL Company

In response to

pgsql-bugs by date

Next:From: Jeff DavisDate: 2011-07-05 17:24:16
Subject: Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)
Previous:From: Tom LaneDate: 2011-07-05 16:42:13
Subject: Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group