Fix null-pointer-deref crash while doing COPY IN with check constraints.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 16 Feb 2015 04:26:45 +0000 (23:26 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 16 Feb 2015 04:26:45 +0000 (23:26 -0500)
commit08361cea2b333189fa3736f2dc6452cef654923d
tree0173d9a4e1d3c1cebe5ff77414a41323b7cf77fe
parentc5b31e29f0128b1c3c1caeeef81b0986cebdcd03
Fix null-pointer-deref crash while doing COPY IN with check constraints.

In commit bf7ca15875988a88e97302e012d7c4808bef3ea9 I introduced an
assumption that an RTE referenced by a whole-row Var must have a valid eref
field.  This is false for RTEs constructed by DoCopy, and there are other
places taking similar shortcuts.  Perhaps we should make all those places
go through addRangeTableEntryForRelation or its siblings instead of having
ad-hoc logic, but the most reliable fix seems to be to make the new code in
ExecEvalWholeRowVar cope if there's no eref.  We can reasonably assume that
there's no need to insert column aliases if no aliases were provided.

Add a regression test case covering this, and also verifying that a sane
column name is in fact available in this situation.

Although the known case only crashes in 9.4 and HEAD, it seems prudent to
back-patch the code change to 9.2, since all the ingredients for a similar
failure exist in the variant patch applied to 9.3 and 9.2.

Per report from Jean-Pierre Pelletier.
src/backend/executor/execQual.c
src/test/regress/expected/copy2.out
src/test/regress/sql/copy2.sql