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

On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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. =A0What 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. =A0That
> 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. =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?

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