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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Chris Bandy" <bandy(dot)chris(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Date: 2011-07-02 03:35:21
Message-ID: 107.1309577721@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Chris Bandy" <bandy(dot)chris(at)gmail(dot)com> writes:
> While using the information_schema to examine my tables, I found that
> "columns"."column_default" does not consistently represent the DEFAULT
> constraint/definition of a column.

> I would expect a column without a DEFAULT definition to return a null value,
> while a column with a DEFAULT definition would return the defined expression
> as a character value.

> In the following log, columns "a", "b" and "c" appear identical though their
> definitions differ.

I don't see anything to fix here. The standard says that for a column
without any explicit default value, COLUMN_DEFAULT should be null.
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. I don't think we're bound to make every
such case work like that, though.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Maksym Boguk 2011-07-02 04:42:36 BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend
Previous Message Tom Lane 2011-07-01 21:59:37 Re: Bug with plpgsql, temp tables and TOAST?