Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Date
Msg-id 29289.1309710675@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently  (Chris Bandy <bandy.chris@gmail.com>)
Responses Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
List 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 by date:

Previous
From: Chris Bandy
Date:
Subject: Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Next
From: Tom Lane
Date:
Subject: Re: BUG #6083: psql script line numbers incorrectly count \copy data