CTAS not honoring NOT NULL, DEFAULT modifiers

From: Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: CTAS not honoring NOT NULL, DEFAULT modifiers
Date: 2010-04-19 06:32:57
Message-ID: q2xa301bfd91004182332ta1620240gac89aa1abe50d87c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)sontakke(at)enterprisedb(dot)com>
Date: Fri, Apr 2, 2010 at 6:07 PM
Subject: CTAS not honoring NOT NULL, DEFAULT modifiers
To: pgsql-patches(at)postgresql(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikhil Sontakke 2010-04-19 06:34:13 row estimation off the mark when generate_series calls are involved
Previous Message Robert Haas 2010-04-19 02:39:47 Re: cost_rescan (was: match_unsorted_outer() vs. cost_nestloop())