CTAS not honoring NOT NULL, DEFAULT modifiers - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject CTAS not honoring NOT NULL, DEFAULT modifiers
Date
Msg-id q2xa301bfd91004182332ta1620240gac89aa1abe50d87c@mail.gmail.com
Whole thread Raw
Responses Re: CTAS not honoring NOT NULL, DEFAULT modifiers  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Guess no-one got to read this email. I sent it to pgsql-patches
without realizing that it is a dead-list. Shouldn't we atleast bounce
emails back to senders if they send an email to pgsql-patches?

Regards,
NIkhils


---------- Forwarded message ----------
From: Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>
Date: Fri, Apr 2, 2010 at 6:07 PM
Subject: CTAS not honoring NOT NULL, DEFAULT modifiers
To: pgsql-patches@postgresql.org


Hi,

I saw this behavior with PG head:

postgres=# create table x(x int default 8 not null);
CREATE TABLE
postgres=# create table x1 as select * from x;
SELECT 0
postgres=# \d x
          Table "public.x"
 Column |  Type   |     Modifiers
--------+---------+--------------------
 x      | integer | not null default 8

postgres=# \d x1
     Table "public.x1"
 Column |  Type   | Modifiers
--------+---------+-----------
 x      | integer |

Note that column x for table x1 did not get the not null modifier. It
also did not get the default values.

Was wondering what are the standards for CTAS. Oracle seems to honor
the NOT NULL modifier. This might be a bug if we do not honor
modifiers in CTAS.

Regards,
Nikhils

--
http://www.enterprisedb.com



--
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: cost_rescan (was: match_unsorted_outer() vs. cost_nestloop())
Next
From: Nikhil Sontakke
Date:
Subject: row estimation off the mark when generate_series calls are involved