Subject: Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in
 child table must be marked NOT NULL
References: <b8794d6a-38f0-9d7c-ad4b-e85adf860fc9@enterprisedb.com>
 <CAB7nPqQY9f3294zYUstHo728srri9WefnrjN6c543+8Z-HGR3Q@mail.gmail.com>
 <25058.1501077775@sss.pgh.pa.us>
 <CAB7nPqQWZf7to5npnTCF7=76nCngVWXtNetX0TEoyctzzfTqSQ@mail.gmail.com>
 <CAB7nPqSdvhZsBbatH-1nS=pKXCorupS3_Xc+=dY9UGQeDsX8jg@mail.gmail.com>
 <8139.1501861816@sss.pgh.pa.us>
 <CAB7nPqS72REPe5WpaY-17y4E9QGf0TtwfwjMKg_HLY9_MRdthQ@mail.gmail.com>
 <CACQjQLrQn8QkEYnURfJ00zVu-CXtcsMBYFUKHadv1H5kdRz9MQ@mail.gmail.com>
 <217ddce6-1b0f-509d-f8e0-5ddd9cad5d86@lab.ntt.co.jp>
 <CAB7nPqStji75D1M=DEkpOXsJbF151m=ZLrJ4jXTh-Czk3kKZ1Q@mail.gmail.com>
 <CACQjQLrN88BrpUAFv-soW+bCnDEkkWGc+z6cmSEMfGMpd+Aa=g@mail.gmail.com>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Message-ID: <107ccc78-1a10-ff59-e837-e5c99dc8c152@lab.ntt.co.jp>
Date: Wed, 13 Dec 2017 17:37:25 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: 
 <CACQjQLrN88BrpUAFv-soW+bCnDEkkWGc+z6cmSEMfGMpd+Aa=g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
To: Ali Akbar <the.apaan@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, tushar <tushar.ahuja@enterprisedb.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Precedence: bulk

On 2017/12/13 15:59, Ali Akbar wrote:
> 2017-12-13 9:10 GMT+07:00 Michael Paquier <michael.paquier@gmail.com>:
> 
>>
>> It is not the first time that this topic shows up. See for example
>> this thread from myself's version of last year:
>> https://www.postgresql.org/message-id/CAB7nPqTPXgX9HiyhhtAgpW7jbA1is
>> kMCSoqXPEEB_KYXYy1E1Q@mail.gmail.com
>> Or this one:
>> http://www.postgresql.org/message-id/21633.1448383428@sss.pgh.pa.us
>>
>> And the conclusion is that we don't want to do what you are doing
>> here, and that it would be better to store NOT NULL constraints in a
>> way similar to CHECK constraints.
>>
> 
> Thanks for the link to those thread.
> 
> Judging from the discussion there, it will be a long way to prevent DROP
> NOT NULL.

Yeah, I remembered that discussion when writing my email, but was for some
reason convinced that everything's fine even without the elaborate
book-keeping of inheritance information for NOT NULL constraints.  Thanks
Michael for reminding.

Thanks,
Amit