From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CTAS not honoring NOT NULL, DEFAULT modifiers |
Date: | 2010-04-20 15:17:15 |
Message-ID: | 201004201517.o3KFHFd19393@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> writes:
> > I think the semantics should be pretty ok as is. But I saw another DB
> > honoring the NOT NULL modifiers and hence the wonder if there is
> > something about this in the standards.
>
> Actually, SQL:2008 does say that if an output column of the SELECT is
> known not nullable, then the created table should have the NOT NULL
> property for that column. We don't implement anything about "known not
> nullable", though, so I'd view this as a small part of an unimplemented
> SQL feature. The usefulness seems rather debatable anyway.
It is supposed to inspect the underlying column or look at the data
values returned and set NOT NULL based on that? The later seems weird.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-04-20 15:24:43 | Re: CTAS not honoring NOT NULL, DEFAULT modifiers |
Previous Message | Robert Haas | 2010-04-20 15:08:06 | Re: RPM script bug #5430 |