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

Chris Bandy <bandy(dot)chris(at)gmail(dot)com> writes:
> On Fri, Jul 1, 2011 at 10:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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