Justin Pryzby <pry...@telsasoft.com> writes: > (gdb) bt > #0 errfinish (dummy=0) at elog.c:414 > #1 0x00000000005d0e30 in ExecEvalScalarVar (exprstate=<value optimized out>, > econtext=<value optimized out>, isNull=<value optimized out>, isDone=<value > optimized out>) at execQual.c:655 > #2 0x00000000005d0c3c in ExecMakeFunctionResultNoSets (fcache=0x21f18a0, > econtext=0x2199e80, isNull=0x21e90ee "", isDone=<value optimized out>) at > execQual.c:2015 > #3 0x000000000059d5ce in ATRewriteTable (tab=<value optimized out>, > OIDNewHeap=<value optimized out>, lockmode=<value optimized out>) at > tablecmds.c:4152 > #4 0x00000000005a92fc in ATRewriteTables (parsetree=0x1f63b20, rel=<value > optimized out>, cmds=<value optimized out>, recurse=<value optimized out>, > lockmode=<value optimized out>) at tablecmds.c:3858 > #5 ATController (parsetree=0x1f63b20, rel=<value optimized out>, cmds=<value > optimized out>, recurse=<value optimized out>, lockmode=<value optimized > out>) at tablecmds.c:3104 > #6 0x00000000006e25e6 in ProcessUtilitySlow (parsetree=0x1fc6f78, > queryString=0x1fc5fb0 "ALTER TABLE eric_umts_rnc_utrancell_metrics ALTER > COLUMN PMSUMPACKETLATENCY_000 TYPE BIGINT USING > PMSUMPACKETLATENCY_000::BIGINT;", > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=<value optimized out>, > completionTag=0x7fff8b9d3a90 "") at utility.c:1085
Okay, so it's clearly processing the USING expression and not something else, which is weird because that should've just been parsed against the existing table column; how could that Var contain the wrong type? I'm wondering if this represents some sort of out-of-sync condition between the table and its child tables. We can't actually tell from this trace which table is being processed. Could you try, from this breakpoint, f 3 p oldrel->rd_rel->relname regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers