Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

Started by Michael Paquierover 9 years ago9 messages
#1Michael Paquier
michael.paquier@gmail.com
1 attachment(s)

Hi all,

A couple of months back the $subject has been mentioned, though nobody
actually wrote a patch to prevent that:
/messages/by-id/21633.1448383428@sss.pgh.pa.us
So here is one..

To put it short, it should not be possible to drop a NOT NULL
constraint on a child relation when its parent table is using it, this
should only be possible from the parent. Attached is a patch handling
this problem by adding a new function in pg_inherits.c to fetch the
list of parent relations for a given relation OID, and did some
refactoring to stick with what is done when scanning child relations.
And here is what this patch can do:
=# create table parent (a int not null);
CREATE TABLE
=# create table child (a int not null);
CREATE TABLE
=# alter table child inherit parent ;
ALTER TABLE
=# alter table child alter COLUMN a drop not null; -- would work on HEAD
ERROR: 42P16: cannot drop NOT NULL constraint for attribute "a"
DETAIL: The same column in parent relation "parent" is marked NOT NULL
LOCATION: ATExecDropNotNull, tablecmds.c:5281
=# alter table parent alter COLUMN a drop not null; -- works on parent
ALTER TABLE
=# \d child
Table "public.child"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
Inherits: parent

I have added a new index to pg_inherits, so that's not something that
could be back-patched, still it would be good to fix this weird
behavior on HEAD. I am adding that to the next CF.
Regards,
--
Michael

Attachments:

child-drop-not-null-v1.patchinvalid/octet-stream; name=child-drop-not-null-v1.patchDownload
diff --git a/src/backend/catalog/pg_inherits.c b/src/backend/catalog/pg_inherits.c
index 00f2ae0..348e8e9 100644
--- a/src/backend/catalog/pg_inherits.c
+++ b/src/backend/catalog/pg_inherits.c
@@ -32,7 +32,121 @@
 #include "utils/tqual.h"
 
 static int	oid_cmp(const void *p1, const void *p2);
+static List *check_rel_entries(Oid *oidarr, int numoids, LOCKMODE lockmode);
 
+/*
+ * check_rel_entries
+ *
+ * Check the existence of relation entries scanned in pg_inherits and
+ * generate a list removing the ones that are deleted.
+ */
+static List *
+check_rel_entries(Oid *oidarr, int numoids, LOCKMODE lockmode)
+{
+	int		i;
+	List   *list = NIL;
+
+	/*
+	 * If we found more than one element, be it parent or child, sort them
+	 * by OID.  This ensures reasonably consistent behavior regardless of
+	 * the vagaries of an indexscan.  This is important since we need to
+	 * be sure all backends lock children in the same order to avoid needless
+	 * deadlocks.
+	 */
+	if (numoids > 1)
+		qsort(oidarr, numoids, sizeof(Oid), oid_cmp);
+
+	/*
+	 * Acquire locks and build the result list.
+	 */
+	for (i = 0; i < numoids; i++)
+	{
+		Oid relid;
+
+		relid = oidarr[i];
+
+		if (lockmode != NoLock)
+		{
+			/* Get the lock to synchronize against concurrent drop */
+			LockRelationOid(relid, lockmode);
+
+			/*
+			 * Now that we have the lock, double-check to see if the relation
+			 * really exists or not.  If not, assume it was dropped while we
+			 * waited to acquire lock, and ignore it.
+			 */
+			if (!SearchSysCacheExists1(RELOID, ObjectIdGetDatum(relid)))
+			{
+				/* Release useless lock */
+				UnlockRelationOid(relid, lockmode);
+				/* And ignore this relation */
+				continue;
+			}
+		}
+
+		list = lappend_oid(list, relid);
+	}
+
+	return list;
+}
+
+/*
+ * find_inheritance_parents
+ *
+ * Returns a list containing the OIDs of all the relations that are direct
+ * parents of the given relation.
+ */
+List *
+find_inheritance_parents(Oid childrelid, LOCKMODE lockmode)
+{
+	List	   *list = NIL;
+	Relation	relation;
+	SysScanDesc	scan;
+	ScanKeyData	key[1];
+	HeapTuple	inheritsTuple;
+	Oid		   *oidarr;
+	int			maxoids,
+				numoids;
+
+	/*
+	 * Scan pg_inherits and build a working array of subclass OIDs.
+	 */
+	maxoids = 32;
+	oidarr = (Oid *) palloc(maxoids * sizeof(Oid));
+	numoids = 0;
+
+	relation = heap_open(InheritsRelationId, AccessShareLock);
+
+	ScanKeyInit(&key[0],
+				Anum_pg_inherits_inhrelid,
+				BTEqualStrategyNumber, F_OIDEQ,
+				ObjectIdGetDatum(childrelid));
+
+	scan = systable_beginscan(relation, InheritsRelidIndexId, true,
+							  NULL, 1, key);
+
+	while ((inheritsTuple = systable_getnext(scan)) != NULL)
+	{
+		Oid parentOid = ((Form_pg_inherits) GETSTRUCT(inheritsTuple))->inhparent;
+		if (numoids >= maxoids)
+		{
+			maxoids *= 2;
+			oidarr = (Oid *) repalloc(oidarr, maxoids * sizeof(Oid));
+		}
+		oidarr[numoids++] = parentOid;
+	}
+
+	systable_endscan(scan);
+
+	heap_close(relation, AccessShareLock);
+
+	/* remove relations potentially already deleted */
+	list = check_rel_entries(oidarr, numoids, lockmode);
+
+	pfree(oidarr);
+
+	return list;
+}
 
 /*
  * find_inheritance_children
@@ -56,8 +170,7 @@ find_inheritance_children(Oid parentrelId, LOCKMODE lockmode)
 	Oid			inhrelid;
 	Oid		   *oidarr;
 	int			maxoids,
-				numoids,
-				i;
+				numoids;
 
 	/*
 	 * Can skip the scan if pg_class shows the relation has never had a
@@ -98,43 +211,8 @@ find_inheritance_children(Oid parentrelId, LOCKMODE lockmode)
 
 	heap_close(relation, AccessShareLock);
 
-	/*
-	 * If we found more than one child, sort them by OID.  This ensures
-	 * reasonably consistent behavior regardless of the vagaries of an
-	 * indexscan.  This is important since we need to be sure all backends
-	 * lock children in the same order to avoid needless deadlocks.
-	 */
-	if (numoids > 1)
-		qsort(oidarr, numoids, sizeof(Oid), oid_cmp);
-
-	/*
-	 * Acquire locks and build the result list.
-	 */
-	for (i = 0; i < numoids; i++)
-	{
-		inhrelid = oidarr[i];
-
-		if (lockmode != NoLock)
-		{
-			/* Get the lock to synchronize against concurrent drop */
-			LockRelationOid(inhrelid, lockmode);
-
-			/*
-			 * Now that we have the lock, double-check to see if the relation
-			 * really exists or not.  If not, assume it was dropped while we
-			 * waited to acquire lock, and ignore it.
-			 */
-			if (!SearchSysCacheExists1(RELOID, ObjectIdGetDatum(inhrelid)))
-			{
-				/* Release useless lock */
-				UnlockRelationOid(inhrelid, lockmode);
-				/* And ignore this relation */
-				continue;
-			}
-		}
-
-		list = lappend_oid(list, inhrelid);
-	}
+	/* remove relations potentially already deleted */
+	list = check_rel_entries(oidarr, numoids, lockmode);
 
 	pfree(oidarr);
 
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 86e9814..cc13982 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -5180,8 +5180,8 @@ ATExecDropNotNull(Relation rel, const char *colName, LOCKMODE lockmode)
 	HeapTuple	tuple;
 	AttrNumber	attnum;
 	Relation	attr_rel;
-	List	   *indexoidlist;
-	ListCell   *indexoidscan;
+	List	   *oidlist;
+	ListCell   *oidscan;
 	ObjectAddress address;
 
 	/*
@@ -5213,11 +5213,11 @@ ATExecDropNotNull(Relation rel, const char *colName, LOCKMODE lockmode)
 	 */
 
 	/* Loop over all indexes on the relation */
-	indexoidlist = RelationGetIndexList(rel);
+	oidlist = RelationGetIndexList(rel);
 
-	foreach(indexoidscan, indexoidlist)
+	foreach(oidscan, oidlist)
 	{
-		Oid			indexoid = lfirst_oid(indexoidscan);
+		Oid			indexoid = lfirst_oid(oidscan);
 		HeapTuple	indexTuple;
 		Form_pg_index indexStruct;
 		int			i;
@@ -5247,7 +5247,45 @@ ATExecDropNotNull(Relation rel, const char *colName, LOCKMODE lockmode)
 		ReleaseSysCache(indexTuple);
 	}
 
-	list_free(indexoidlist);
+	list_free(oidlist);
+
+	/*
+	 * Check if parent relations have a NOT NULL constraint on this column
+	 * and throw an error if that is the case.  All the direct parent
+	 * relations found in pg_inherits are checked.
+	 */
+	oidlist = find_inheritance_parents(RelationGetRelid(rel), lockmode);
+
+	foreach(oidscan, oidlist)
+	{
+		Oid			parentoid = lfirst_oid(oidscan);
+		HeapTuple	tuple;
+		Relation	attr_rel;
+		Form_pg_attribute parentatt;
+
+		attr_rel = heap_open(AttributeRelationId, RowExclusiveLock);
+
+		tuple = SearchSysCacheCopyAttName(parentoid, colName);
+		if (!HeapTupleIsValid(tuple))	/* shouldn't happen */
+			elog(ERROR, "cache lookup failed for attribute \"%s\" of relation %u",
+				 colName, parentoid);
+
+		parentatt = (Form_pg_attribute) GETSTRUCT(tuple);
+
+		if (parentatt->attnotnull)
+			ereport(ERROR,
+					(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
+					 errmsg("cannot drop NOT NULL constraint for attribute \"%s\"",
+							colName),
+					 errdetail("The same column in parent relation \"%s\" is marked NOT NULL.",
+							   get_rel_name(parentoid))));
+
+		heap_freetuple(tuple);
+
+		heap_close(attr_rel, NoLock);
+	}
+
+	list_free(oidlist);
 
 	/*
 	 * Okay, actually perform the catalog change ... if needed
diff --git a/src/include/catalog/indexing.h b/src/include/catalog/indexing.h
index ca5eb3d..dffa15f 100644
--- a/src/include/catalog/indexing.h
+++ b/src/include/catalog/indexing.h
@@ -161,6 +161,8 @@ DECLARE_UNIQUE_INDEX(pg_inherits_relid_seqno_index, 2680, on pg_inherits using b
 #define InheritsRelidSeqnoIndexId  2680
 DECLARE_INDEX(pg_inherits_parent_index, 2187, on pg_inherits using btree(inhparent oid_ops));
 #define InheritsParentIndexId  2187
+DECLARE_INDEX(pg_inherits_relid_index, 3343, on pg_inherits using btree(inhrelid oid_ops));
+#define InheritsRelidIndexId  3343
 
 DECLARE_UNIQUE_INDEX(pg_init_privs_o_c_o_index, 3395, on pg_init_privs using btree(objoid oid_ops, classoid oid_ops, objsubid int4_ops));
 #define InitPrivsObjIndexId  3395
diff --git a/src/include/catalog/pg_inherits_fn.h b/src/include/catalog/pg_inherits_fn.h
index a717108..bb924ed 100644
--- a/src/include/catalog/pg_inherits_fn.h
+++ b/src/include/catalog/pg_inherits_fn.h
@@ -17,6 +17,7 @@
 #include "nodes/pg_list.h"
 #include "storage/lock.h"
 
+extern List *find_inheritance_parents(Oid childrelid, LOCKMODE lockmode);
 extern List *find_inheritance_children(Oid parentrelId, LOCKMODE lockmode);
 extern List *find_all_inheritors(Oid parentrelId, LOCKMODE lockmode,
 					List **parents);
diff --git a/src/test/regress/expected/alter_table.out b/src/test/regress/expected/alter_table.out
index 3232cda..026233c 100644
--- a/src/test/regress/expected/alter_table.out
+++ b/src/test/regress/expected/alter_table.out
@@ -2914,3 +2914,15 @@ Table "public.test_add_column"
  c4     | integer | 
 
 DROP TABLE test_add_column;
+-- tests for NOT NULL with inherited tables
+CREATE TABLE parent_drop_null (id int NOT NULL);
+CREATE TABLE child_drop_null (id int);
+ALTER TABLE child_drop_null INHERIT parent_drop_null; -- error
+ERROR:  column "id" in child table must be marked NOT NULL
+ALTER TABLE child_drop_null ALTER COLUMN id SET NOT NULL;
+ALTER TABLE child_drop_null INHERIT parent_drop_null; -- ok
+ALTER TABLE child_drop_null ALTER COLUMN id DROP NOT NULL; -- error
+ERROR:  cannot drop NOT NULL constraint for attribute "id"
+DETAIL:  The same column in parent relation "parent_drop_null" is marked NOT NULL.
+DROP TABLE child_drop_null;
+DROP TABLE parent_drop_null;
diff --git a/src/test/regress/sql/alter_table.sql b/src/test/regress/sql/alter_table.sql
index 72e65d4..bd40297 100644
--- a/src/test/regress/sql/alter_table.sql
+++ b/src/test/regress/sql/alter_table.sql
@@ -1842,3 +1842,13 @@ ALTER TABLE test_add_column
 	ADD COLUMN c4 integer;
 \d test_add_column
 DROP TABLE test_add_column;
+
+-- tests for NOT NULL with inherited tables
+CREATE TABLE parent_drop_null (id int NOT NULL);
+CREATE TABLE child_drop_null (id int);
+ALTER TABLE child_drop_null INHERIT parent_drop_null; -- error
+ALTER TABLE child_drop_null ALTER COLUMN id SET NOT NULL;
+ALTER TABLE child_drop_null INHERIT parent_drop_null; -- ok
+ALTER TABLE child_drop_null ALTER COLUMN id DROP NOT NULL; -- error
+DROP TABLE child_drop_null;
+DROP TABLE parent_drop_null;
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#1)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

Michael Paquier <michael.paquier@gmail.com> writes:

To put it short, it should not be possible to drop a NOT NULL
constraint on a child relation when its parent table is using it, this
should only be possible from the parent. Attached is a patch handling
this problem by adding a new function in pg_inherits.c to fetch the
list of parent relations for a given relation OID, and did some
refactoring to stick with what is done when scanning child relations.

This doesn't sound like the right approach; in particular, it won't really
help for deciding whether to propagate a DROP NOT NULL on a parent rel to
its children. What we've discussed in the past is to store NOT NULL
constraints in pg_constraint, much like CHECK constraints are already, and
use use-count logic identical to the CHECK case to keep track of whether
NOT NULL constraints are inherited or not. My feeling is that we'd keep
the pg_attribute.attnotnull field and continue to drive actual enforcement
off that, but it would just reflect a summary of the pg_constraint state.

IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the
current state is.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Michael Paquier
michael.paquier@gmail.com
In reply to: Tom Lane (#2)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:
This doesn't sound like the right approach; in particular, it won't really
help for deciding whether to propagate a DROP NOT NULL on a parent rel to
its children. What we've discussed in the past is to store NOT NULL
constraints in pg_constraint, much like CHECK constraints are already, and
use use-count logic identical to the CHECK case to keep track of whether
NOT NULL constraints are inherited or not. My feeling is that we'd keep
the pg_attribute.attnotnull field and continue to drive actual enforcement
off that, but it would just reflect a summary of the pg_constraint state.

OK, I see. Hm, by storing this information I would actually think that
we want to drop this attnotnull so as we don't need to bother about
updating pg_attribute through the whole tree when dropping a NOT NULL
constraint on the parent, and we do not actually need to store this
information in two different places..

I would also rather do nothing for the DDL interface regarding for
example the possibility to change the constraint names for domains and
tables to keep things simple. A patch of this caliber would be
complicated enough if a catalog switch is done.

IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the
current state is.

Are you talking about that?
/messages/by-id/20110707213401.GA27098@alvh.no-ip.org
This is not a small patch :)

Alvaro, others, any opinions?
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#4Vitaly Burovoy
vitaly.burovoy@gmail.com
In reply to: Tom Lane (#2)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On 6/15/16, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

To put it short, it should not be possible to drop a NOT NULL
constraint on a child relation when its parent table is using it, this
should only be possible from the parent. Attached is a patch handling
this problem by adding a new function in pg_inherits.c to fetch the
list of parent relations for a given relation OID, and did some
refactoring to stick with what is done when scanning child relations.

This doesn't sound like the right approach; in particular, it won't really
help for deciding whether to propagate a DROP NOT NULL on a parent rel to
its children. What we've discussed in the past is to store NOT NULL
constraints in pg_constraint, much like CHECK constraints are already, and
use use-count logic identical to the CHECK case to keep track of whether
NOT NULL constraints are inherited or not. My feeling is that we'd keep
the pg_attribute.attnotnull field and continue to drive actual enforcement
off that, but it would just reflect a summary of the pg_constraint state.

IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the
current state is.

regards, tom lane

The last thread about NOT NULLs as constraints is accessible by the link[1]/messages/by-id/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com.
I rebased[2]/messages/by-id/attachment/41886/catalog-notnull-2-c477e84_cleaned.patch Alvaro's patch to the actual master at that time, but I
have not repeated it since then.

In the initial letter[1]/messages/by-id/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com I posted a digest from the SQL-2011 standard
and a conclusion as a design of a new patch.
Now I have more free time and I'm hacking it that way. The new patch
is at the very early stage, full of WIPs and TODOs. I hope it'll be
ready to be shown in a month (may be two).

But it already forbids dropping NOT NULLs if they were set as result
of inheritance.

[1]: /messages/by-id/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com
[2]: /messages/by-id/attachment/41886/catalog-notnull-2-c477e84_cleaned.patch

--
Best regards,
Vitaly Burovoy

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#5Michael Paquier
michael.paquier@gmail.com
In reply to: Vitaly Burovoy (#4)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy
<vitaly.burovoy@gmail.com> wrote:

In the initial letter[1] I posted a digest from the SQL-2011 standard
and a conclusion as a design of a new patch.
Now I have more free time and I'm hacking it that way. The new patch
is at the very early stage, full of WIPs and TODOs. I hope it'll be
ready to be shown in a month (may be two).

I have just read both your patch and the one of Alvaro, but yours does
not touch pg_constraint in any way. Isn't that unexpected?

But it already forbids dropping NOT NULLs if they were set as result
of inheritance.

Okay, I'll drop any proposal on my side in this case. Looking forward
to seeing what you got for the first commit fest of 10.0.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#6Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Michael Paquier (#3)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

Michael Paquier wrote:

On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the
current state is.

Are you talking about that?
/messages/by-id/20110707213401.GA27098@alvh.no-ip.org
This is not a small patch :)

Alvaro, others, any opinions?

I haven't looked at this in a while. I suppose I should get it in shape
sometime. Unless you would like to work on it?

Note that Vitaly Burovoy rebased it, but I think the rebase is wrong.
/messages/by-id/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#7Michael Paquier
michael.paquier@gmail.com
In reply to: Alvaro Herrera (#6)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On Thu, Jun 16, 2016 at 1:27 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Michael Paquier wrote:

On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the
current state is.

Are you talking about that?
/messages/by-id/20110707213401.GA27098@alvh.no-ip.org
This is not a small patch :)

Alvaro, others, any opinions?

I haven't looked at this in a while. I suppose I should get it in shape
sometime. Unless you would like to work on it?

Well, I could, but there is another big patch I am getting into shape
for the next CF (Ahem. scram. Ahem), so I am going to stay focused on
this one to have fuel for it during the CF. But I'm fine reviewing the
patch for the DROP NOT NULL.

Note that Vitaly Burovoy rebased it, but I think the rebase is wrong.
/messages/by-id/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com

Yes, it is definitely wrong.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#8Vitaly Burovoy
vitaly.burovoy@gmail.com
In reply to: Michael Paquier (#5)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On 6/15/16, Michael Paquier <michael.paquier@gmail.com> wrote:

On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy
<vitaly.burovoy@gmail.com> wrote:

In the initial letter[1] I posted a digest from the SQL-2011 standard
and a conclusion as a design of a new patch.
Now I have more free time and I'm hacking it that way. The new patch
is at the very early stage, full of WIPs and TODOs. I hope it'll be
ready to be shown in a month (may be two).

I have just read both your patch and the one of Alvaro, but yours does
not touch pg_constraint in any way. Isn't that unexpected?

The consensus was reached to use CHECK constraints instead of new type
of constrains.
Alvaro made attempt[1]/messages/by-id/1343682669-sup-2532@alvh.no-ip.org to write PoC in 2012 but it failed to apply on
top of master (and after solving conflicts led to core dumps) in Jan
2016.

I just rebased Alvaro's one to understand how he wanted to solve issue
and to run tests and queries. After all I sent rebased working patch
for anyone who wants to read it and try it without core dumps.

I have not published my patch for NOT NULLs yet.

Alvaro, the correct path[2]/messages/by-id/attachment/41886/catalog-notnull-2-c477e84_cleaned.patch in the second message[3]/messages/by-id/CAKOSWNnXbOY4pEiwN9wePOx8J+B44yTj40BQ8RVo-eWkdiGDFQ@mail.gmail.com -- Best regards, Vitaly Burovoy of the thread.
What's wrong in it (I got the source in the previous[1]/messages/by-id/1343682669-sup-2532@alvh.no-ip.org thread)?

[1]: /messages/by-id/1343682669-sup-2532@alvh.no-ip.org
[2]: /messages/by-id/attachment/41886/catalog-notnull-2-c477e84_cleaned.patch
[3]: /messages/by-id/CAKOSWNnXbOY4pEiwN9wePOx8J+B44yTj40BQ8RVo-eWkdiGDFQ@mail.gmail.com -- Best regards, Vitaly Burovoy
--
Best regards,
Vitaly Burovoy

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#9Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#3)
Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

Michael Paquier <michael.paquier@gmail.com> writes:

On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

My feeling is that we'd keep
the pg_attribute.attnotnull field and continue to drive actual enforcement
off that, but it would just reflect a summary of the pg_constraint state.

OK, I see. Hm, by storing this information I would actually think that
we want to drop this attnotnull so as we don't need to bother about
updating pg_attribute through the whole tree when dropping a NOT NULL
constraint on the parent, and we do not actually need to store this
information in two different places..

There are a couple of reasons for not removing attnotnull: one is to not
need to touch the executor for this, and another is to not break
client-side code that is accustomed to looking at attnotnull.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers