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
Import Notes
Reply to msg id not found: 1214501747.6336.12.camel@tux64.privat
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 {CREATESTMTOh, 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