On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Gee, does Noah's recent patch adding the notion of "transform functions" have any applicability to this problem? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
