Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 340409F9386 for ; Tue, 19 Dec 2006 15:34:10 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 22328-01 for ; Tue, 19 Dec 2006 15:33:56 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id 73DB49FA380 for ; Tue, 19 Dec 2006 15:33:51 -0400 (AST) Received: from mainbox.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id F0EDE74190; Tue, 19 Dec 2006 19:33:45 +0000 (GMT) Received: from [192.168.1.17] (client17.office.archonet.com [192.168.1.17]) by mainbox.archonet.com (Postfix) with ESMTP id 85598FF04; Tue, 19 Dec 2006 19:33:44 +0000 (GMT) Message-ID: <45883E98.7080505@archonet.com> Date: Tue, 19 Dec 2006 19:33:44 +0000 From: Richard Huxton User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: George Pavlov Cc: Markus Schaber , pgsql-sql@postgresql.org Subject: Re: null values in non-nullable column References: <8C5B026B51B6854CBE88121DBF097A866A48A9@ehost010-33.exch010.intermedia.net> In-Reply-To: <8C5B026B51B6854CBE88121DBF097A866A48A9@ehost010-33.exch010.intermedia.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/138 X-Sequence-Number: 27094 George Pavlov wrote: > Even though, as Tom Lane explained, CREATE TABLE AS is not the problem > here, it seems to me that might be the cleanest, least obtrusive place > to add validation. If C.T.A failed at the table creation step because of > the JOIN-produces NULLs that would be an early and decent warning. > Fixing it from the JOIN side (e.g. disallowing NULL-generating JOINs on > NOT NULL domains) seems too strict -- JOINs are mostly used for result > sets that are not materialized and you hardly have the potential for a > problem until they are materialized as a table. Similarly, removing the > domain-ness of the JOIN column strikes me as too drastic and as having > the potential of breaking existing functionality. I am sure I am missing > something, just my two cents... I think it has to go in the join... If a result-set has nulls in a particular column, that column can't be NOT NULL (by definition). Therefore, either the column has its not-null constraint removed (through type-casting away the domain) or the query fails on that NOT NULL constraint. Any query could result in this sort of problem, not just an explicit JOIN with NULLs. Imagine a domain "even_numbers_only" and a "SELECT my_even_numbers+1 FROM foo". Hmm - it strikes me that any result-set should perhaps have the domain removed and substituted with its parent type, except perhaps in the simplest "pass column through" case. -- Richard Huxton Archonet Ltd