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
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? |