Thread: BUG #16386: drop contraint in inherited table is missing in pg_dump backup

BUG #16386: drop contraint in inherited table is missing in pg_dump backup

From
PG Bug reporting form
Date:
The following bug has been logged on the website:

Bug reference:      16386
Logged by:          klement szabolcs
Email address:      szittya314@gmail.com
PostgreSQL version: 10.12
Operating system:   centos 7
Description:

create table b (aaa int primary key,bb date );
create table A (id int primary key) inherits (B);
alter table a alter column aaa drop not null;

after i made pg_dump and pg_restore the not null contraint isexist on table
a;


Re: BUG #16386: drop contraint in inherited table is missing inpg_dump backup

From
Euler Taveira
Date:
On Fri, 24 Apr 2020 at 07:09, PG Bug reporting form <noreply@postgresql.org> wrote:

create table b (aaa int primary key,bb date );
create table A (id int primary key) inherits (B);
alter table a alter column aaa drop not null;

after i made pg_dump and pg_restore the not null contraint isexist on table
a;

It does not make sense to exclude a not null constraint on an inherited table because column "aaa" can be null in table "a" but a SELECT in table "b" will return a NULL for a primary key (ugh). It is just one of the ways to shoot yourself in the foot. If you check CREATE TABLE synopsis, there isn't NO INHERIT for not null constraints. Maybe it is worth adding a note in CREATE TABLE.


--
Euler Taveira                 http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: BUG #16386: drop contraint in inherited table is missing inpg_dump backup

From
Alvaro Herrera
Date:
On 2020-Apr-24, Euler Taveira wrote:

> On Fri, 24 Apr 2020 at 07:09, PG Bug reporting form <noreply@postgresql.org>
> wrote:
> 
> > create table b (aaa int primary key,bb date );
> > create table A (id int primary key) inherits (B);
> > alter table a alter column aaa drop not null;
> >
> > after i made pg_dump and pg_restore the not null contraint isexist on table
> > a;
> >
> It does not make sense to exclude a not null constraint on an inherited
> table because column "aaa" can be null in table "a" but a SELECT in table
> "b" will return a NULL for a primary key (ugh). It is just one of the ways
> to shoot yourself in the foot. If you check CREATE TABLE synopsis, there
> isn't NO INHERIT for not null constraints. Maybe it is worth adding a note
> in CREATE TABLE.

I agree with your analysis, but in that case we should make the DROP NOT
NULL throw an error instead of proceeding.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Apr-24, Euler Taveira wrote:
>> On Fri, 24 Apr 2020 at 07:09, PG Bug reporting form <noreply@postgresql.org>
>> wrote:
>>> create table b (aaa int primary key,bb date );
>>> create table A (id int primary key) inherits (B);
>>> alter table a alter column aaa drop not null;

>> It does not make sense to exclude a not null constraint on an inherited
>> table because column "aaa" can be null in table "a" but a SELECT in table
>> "b" will return a NULL for a primary key (ugh). It is just one of the ways
>> to shoot yourself in the foot. If you check CREATE TABLE synopsis, there
>> isn't NO INHERIT for not null constraints. Maybe it is worth adding a note
>> in CREATE TABLE.

> I agree with your analysis, but in that case we should make the DROP NOT
> NULL throw an error instead of proceeding.

Indeed, but we lack the catalog infrastructure to do that reasonably.
If we ever get around to creating pg_constraint entries for NOT NULL
constraints, it'd be simple to do, since those would carry info about
whether or not the constraint is inherited.  (Weren't you working on
that awhile ago?)

            regards, tom lane