On 2015-08-04 PM 05:58, Geoff Winkless wrote: > > ​Although it seems Amit has defined the problem better than I could, so > this is a bit late to the party (!), yes, the table had been ALTERed after > it was created (looking back through the history, that modification > included at least one DROP COLUMN). >
It seems using any columns that used to be after a dropped columns cause EXCLUDE pseudo-relation to misbehave. For example, I observed another symptom: test=# CREATE TABLE upsert_fail_test(a int, b int, c int, d smallint); CREATE TABLE test=# ALTER TABLE upsert_fail_test DROP b; ALTER TABLE test=# ALTER TABLE upsert_fail_test ADD PRIMARY KEY (a, c, d); ALTER TABLE test=# INSERT INTO upsert_fail_test(a, c, d) VALUES (1, 2, 3) ON CONFLICT (a, c, d) DO UPDATE SET c = EXCLUDED.c; INSERT 0 1 test=# INSERT INTO upsert_fail_test(a, c, d) VALUES (1, 2, 3) ON CONFLICT (a, c, d) DO UPDATE SET c = EXCLUDED.c; ERROR: null value in column "c" violates not-null constraint DETAIL: Failing row contains (1, null, 3). Or, the EXCLUDED pseudo-rel failed to deliver '2' produced by the subplan and instead produced a 'null' which I guess was caused by the dropped column 'b'. Perhaps, it may have to do with how EXCLUDED pseudo-rel's targetlist is manipulated through parse-plan stage? Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
