On Mon, Jan 16, 2017 at 4:09 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > The problem is that whereas the SlotValueDescription that we build to show > in the error message should be based on the tuple that was passed to > ExecInsert() or whatever NextCopyFrom() returned for CopyFrom() to > process, it might fail to be the case if the tuple was needed to be > converted after tuple routing. slot (the tuple in it and its tuple > descriptor) and resultRelInfo that ExecConstraint() receives *do* > correspond with each other, even after possible tuple conversion following > tuple-routing, and hence constraint checking itself works fine (since > commit 2ac3ef7a01 [1]). As said, it's the val_desc built to show in the > error message being based on the converted-for-partition tuple that could > be seen as a problem - is it acceptable if we showed in the error message > whatever the converted-for-partition tuple looks like which might have > columns ordered differently from the root table? If so, we could simply > forget the whole thing, including reverting f1b4c771 [2]. > > An example: > > create table p (a int, b char, c int) partition by list (a); > create table p1 (b char, c int, a int); -- note the column order > alter table p attach partition p1 for values in (1); > alter table p add constraint check_b check (b = 'x'); > > insert into p values (1, 'y', 1); > ERROR: new row for relation "p1" violates check constraint "check_b" > DETAIL: Failing row contains (y, 1, 1). > > Note that "(y, 1, 1)" results from using p1's descriptor on the converted > tuple. As long that's clear and acceptable, I think we need not worry > about this patch and revert the previously committed patch for this "problem".
Hmm. It would be fine, IMHO, if the detail message looked like the one that BuildIndexValueDescription produces. Without the column names, the clarity is somewhat lessened. Anybody else have an opinion on this? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
