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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Дата
Msg-id 29289.1309710675@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently  (Chris Bandy <bandy.chris@gmail.com>)
Ответы Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-bugs
Chris Bandy <bandy.chris@gmail.com> writes:
> On Fri, Jul 1, 2011 at 10:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But AFAICS there is room for implementation dependency in other cases.
>> In the particular cases you show here, PG recognizes some of them as
>> being equivalent to not having a default value, so for efficiency's sake
>> it converts them to that form.

> That makes sense, too. Perhaps I am naive, but a null is a null,
> right? Is the different presentation of defaults for "d" and "e"
> indicative of an *in*efficiency in PG?

Yeah, it's intentional though.  What the printout is not telling you
is that there's a hidden cast function invocation to enforce the length
limit in the cases where the column has an explicit length limit.  That
is, under the hood the expression is really more like "varchar(NULL, 1)".
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.

            regards, tom lane

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

Предыдущее
От: Chris Bandy
Дата:
Сообщение: Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #6083: psql script line numbers incorrectly count \copy data