Re: inheritance, and plans

so Tom,
with a little help on Irc from Andrew (RhodiumToad) I got it 'fixed',
but I know this is just a hack:

Index: src/backend/utils/adt/selfuncs.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/selfuncs.c,v
retrieving revision 1.258
diff -u -r1.258 selfuncs.c
--- src/backend/utils/adt/selfuncs.c    1 Jan 2009 17:23:50 -0000    1.258
+++ src/backend/utils/adt/selfuncs.c    7 Feb 2009 17:20:21 -0000
@@ -3392,7 +3392,7 @@
 static double
 convert_numeric_to_scalar(Datum value, Oid typid)
 {
-    switch (typid)
+    switch (getBaseType(typid))
     {
         case BOOLOID:
             return (double) DatumGetBool(value);
ndex: src/backend/optimizer/path/allpaths.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/optimizer/path/allpaths.c,v
retrieving revision 1.179
diff -u -r1.179 allpaths.c
--- src/backend/optimizer/path/allpaths.c    1 Jan 2009 17:23:43 -0000    1.179
+++ src/backend/optimizer/path/allpaths.c    7 Feb 2009 17:21:25 -0000
@@ -33,6 +33,9 @@
 #include "parser/parse_clause.h"
 #include "parser/parsetree.h"
 #include "rewrite/rewriteManip.h"
+#include "utils/lsyscache.h"
+#include "utils/syscache.h"
+


 /* These parameters are set by GUC */
@@ -1042,7 +1045,7 @@
             continue;            /* ignore resjunk columns */
         if (colType == NULL)
             elog(ERROR, "wrong number of tlist entries");
-        if (exprType((Node *) tle->expr) != lfirst_oid(colType))
+        if (exprType((Node *) tle->expr) != lfirst_oid(colType) &&
getBaseType(exprType((Node *) tle->expr)) != lfirst_oid(colType))
             differentTypes[tle->resno] = true;
         colType = lnext(colType);
     }




This is just a hack, and I know it won't work. But the question is, is
it possible to fix it ?
I think something should convert types to base type somewhere up the
call level. Perhaps we should pass on oid of type+baseType ?

I also noticed that the  convert_numeric_to_scalar() family of
functions is considered a future change too, atm everything there is
hardcoded pretty much.