Chris Bandy <bandy.ch...@gmail.com> writes: > On Fri, Jul 1, 2011 at 10:35 PM, Tom Lane <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs