Re: BUG #8408: Not exactly correct error messages for failed check in presence of dropped columns.

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Fri, Aug 30, 2013 at 2:13 PM, <maxim(dot)boguk(at)gmail(dot)com> wrote:
>> However, I think error message should filter dropped column and strange null
>> values (because if a table has a lot dropped column this error message
>> quickly become completely unreadable).

> Yes, this is not really user-friendly. This comes from
> ExecBuildSlotValueDescription(at)execMain(dot)c when generating a string
> representation of a tuple. Attached is a patch to make this function
> aware of dropped columns when generating the string (usable down to
> 9.2). However, after some debugging I am seeing that the dropped
> column is not seen inside TupleDesc (only the column name is correct)
> when calling this function in executor.

I got around to looking at this finally, and found out that the reason
Michael's patch doesn't work is that the slot's tuple descriptor is one
that's been made by ExecAssignResultTypeFromTL from the result targetlist
the planner generates, so it has no dropped-column markings. (The
targetlist includes a simple null constant at any dropped column's
position; but TargetEntry has no way to mark itself as a dropped column.)
I think it was coded that way to minimize ExecBuildSlotValueDescription's
API complexity, but really what we ought to do is pass the actual target
relation's tuple descriptor, which will have the necessary markings.
The attached revision of Michael's patch fixes it.

regards, tom lane