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.
Breakpoint 1, ExecBuildSlotValueDescription (slot=0x7fc26412b8e0,
maxfieldlen=64) at execMain.c:1636
1636 TupleDesc tupdesc = slot->tts_tupleDescriptor;
(gdb) p *tupdesc->attrs[0]
$1 = {
attrelid = 0,
attname = {
data = "id", '\0' <repeats 61 times>
},
atttypid = 23,
attstattarget = -1,
attlen = 4,
attnum = 1,
attndims = 0,
attcacheoff = 0,
atttypmod = -1,
attbyval = 1 '\001',
attstorage = 112 'p',
attalign = 105 'i',
attnotnull = 0 '\0',
atthasdef = 0 '\0',
attisdropped = 0 '\0',
attislocal = 1 '\001',
attinhcount = 0,
attcollation = 0
}
(gdb) p *tupdesc->attrs[1]
$2 = {
attrelid = 0,
attname = {
data = "........pg.dropped.2........", '\0' <repeats 35 times>
},
atttypid = 23,
attstattarget = -1,
attlen = 4,
attnum = 2,
attndims = 0,
attcacheoff = -1,
atttypmod = -1,
attbyval = 1 '\001',
attstorage = 112 'p',
attalign = 105 'i',
attnotnull = 0 '\0',
atthasdef = 0 '\0',
attisdropped = 0 '\0',
attislocal = 1 '\001',
attinhcount = 0,
attcollation = 0
}
attisdropped is not set to true, only attname is updated to its new value.
When removing an attribute in RemoveAttributeById, it is written in
comment that updating a pg_attribute row triggers a relcache flush for
target relation, but obviously it is not happening. I am missing
something perhaps?
--
Michael