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: CA+TgmobOqhUu=C=-h0EGWRuL_k-nwJDP6E6iG_6967G4zvtD9w@mail.gmail.com (view raw or flat)
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
EnterpriseDB: http://www.enterprisedb.com
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-2014 The PostgreSQL Global Development Group