Thread: BUG #4266: regress test: could not dump unrecognized node type: 925
The following bug has been logged online: Bug reference: 4266 Logged by: Clemens Fischer Email address: clefis@gmx.de PostgreSQL version: 8.3.3 Operating system: QNX Description: regress test: could not dump unrecognized node type: 925 Details: I cannot decode this bug on the TODO list. There is no fix in the snapshot from today. The bug is platform independent. A part of the regress tests fails 'cause in src/backend/nodes/outfuncs.c the function _outInhRelation() is missing. The solution is a little patch: diff -Prubd postgresql-8.3.3/src/backend/nodes/outfuncs.c postgresql-8.3.3-1/src/backend/nodes/outfuncs.c --- postgresql-8.3.3/src/backend/nodes/outfuncs.c 2008-01-09 09:46:44.000000000 +0100 +++ postgresql-8.3.3-1/src/backend/nodes/outfuncs.c 2008-06-25 13:59:46.000000000 +0200 @@ -1547,6 +1547,15 @@ } static void +_outInhRelation(StringInfo str, InhRelation *node) +{ + WRITE_NODE_TYPE("INHRELATION"); + + WRITE_NODE_FIELD(relation); + WRITE_NODE_FIELD(options); +} + +static void _outIndexStmt(StringInfo str, IndexStmt *node) { WRITE_NODE_TYPE("INDEXSTMT"); @@ -2357,6 +2366,9 @@ case T_CreateStmt: _outCreateStmt(str, obj); break; + case T_InhRelation: + _outInhRelation(str, obj); + break; case T_IndexStmt: _outIndexStmt(str, obj); break;
"Clemens Fischer" <clefis@gmx.de> writes: > A part of the regress tests fails 'cause in src/backend/nodes/outfuncs.c the > function _outInhRelation() is missing. What part of which regression tests? No one else is reporting problems. regards, tom lane
"Clemens A. Fischer" <clefis@gmx.de> writes: > here is a part of the output of the regression test: > WARNING: could not dump unrecognized node type: 925 > DEBUG: parse tree: > DETAIL: {QUERY :commandType 5 :querySource 0 :canSetTag > true :utilityStmt {CREATESTMT Oh, you've got debug_print_parse turned on. I'm not especially excited about trying to make the regression tests pass under random nondefault settings --- we could expend large amounts of effort that way, to very little purpose. regards, tom lane
Tom Lane wrote: > "Clemens A. Fischer" <clefis@gmx.de> writes: > > here is a part of the output of the regression test: > > WARNING: could not dump unrecognized node type: 925 > > DEBUG: parse tree: > > DETAIL: {QUERY :commandType 5 :querySource 0 :canSetTag > > true :utilityStmt {CREATESTMT > > Oh, you've got debug_print_parse turned on. I'm not especially excited > about trying to make the regression tests pass under random nondefault > settings --- we could expend large amounts of effort that way, to very > little purpose. But doesn't the failure indicate a potential problem that the regression tests are pointing out? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > Tom Lane wrote: >> Oh, you've got debug_print_parse turned on. > But doesn't the failure indicate a potential problem that the regression > tests are pointing out? Only that outfuncs.c has very incomplete coverage of utility statements. regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> Oh, you've got debug_print_parse turned on. > > > But doesn't the failure indicate a potential problem that the regression > > tests are pointing out? > > Only that outfuncs.c has very incomplete coverage of utility statements. Oh, so we don't guarantee that debug_print_parse will always work. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > Tom Lane wrote: >> Only that outfuncs.c has very incomplete coverage of utility statements. > Oh, so we don't guarantee that debug_print_parse will always work. Well, we have never bothered to make it dump everything in the utility-statement universe, and I don't especially want to start now --- if that were worth doing we'd have done it before now. I notice that _outQuery already contains a filter that's intended to prevent warning chatter of exactly this type. I think it's probably at least as logical to fix this issue by removing dumping of CreateStmt as to try to ensure that we know how to dump everything that could appear underneath CreateStmt ... regards, tom lane