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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Дата
Msg-id CA+TgmobOqhUu=C=-h0EGWRuL_k-nwJDP6E6iG_6967G4zvtD9w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Tue, Jul 5, 2011 at 12:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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. =A0In 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. =A0If 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. =A0But it seems unlikely to be worth
> the cycles in most cases. =A0Also, we'd then need some other test to
> address the issue explained in AddRelationNewConstraints:
>
> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * If the expression is just a NULL constant, we do not bo=
ther to make
> =A0 =A0 =A0 =A0 * an explicit pg_attrdef entry, since the default behavio=
r is
> =A0 =A0 =A0 =A0 * equivalent.
> =A0 =A0 =A0 =A0 *
> =A0 =A0 =A0 =A0 * Note a nonobvious property of this test: if the column =
is of a
> =A0 =A0 =A0 =A0 * domain type, what we'll get is not a bare null Const bu=
t a
> =A0 =A0 =A0 =A0 * CoerceToDomain expr, so we will not discard the default=
. =A0This is
> =A0 =A0 =A0 =A0 * critical because the column default needs to be retaine=
d to
> =A0 =A0 =A0 =A0 * override any default that the domain might have.
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0if (expr =3D=3D NULL ||
> =A0 =A0 =A0 =A0 =A0 =A0(IsA(expr, Const) &&((Const *) expr)->constisnull))
> =A0 =A0 =A0 =A0 =A0 =A0continue;
>
> 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.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)