because as long as it has parameters declared internal,
no SQL can ever call it.
I was confused about the difference between anyelement and
internal, and I want to know a way to create a function which
is disallowed to be called by the user. Your above words
resolved two questions of mine!
So it can only appear in an expression
tree because your SupportRequestSimplify put it there properly
typed, after the SQL query was parsed but before evaluation.
The thing about 'internal' is it doesn't represent any specific
type, it doesn't necessarily represent the same type every time it
is mentioned, and it often means something that isn't a cataloged
type at all, such as a pointer to some kind of struct.
I should have noticed this during the study planner support function,
but highlighting this is pretty amazing.
If there isn't, one might have to be invented. So it might be that
if we go down the "use polymorphic resolution" road, we have to
invent dummy Consts, and down the "internal" road we also have to
invent something.
I think you might already feel that putting an internal function
into an expression would cause something wrong. I just have
a quick hack on this, and crash happens at the simplest case.
If something already exists to fix this, I am inclined
to use 'internal', but I didn't find the way. I'm thinking if we
should clarify "internal" should only be used internally and
should never be used in expression by design?
(And I'm not even sure anything has to be invented. If there's an
existing node for no-op binary casts, I think I'd first try
putting that there and see if anything complains.)
If this thread is being followed by others more familiar with
the relevant code or who see obvious problems I'm missing,
please chime in!
Thank you wise & modest gentleman, I would really hope Tom can
chime in at this time.
In general, the current decision we need to make is shall we use
'internal' or 'anyelement' to present the target OID. the internal way
would be more straight but have troubles to be in the expression tree.
the 'anyelement' way is compatible with expression, but it introduces
the makeDummyConst overhead and I'm not pretty sure it is a correct
implementation in makeDummyConst. see the XXX part.
+/*
+ * makeDummyConst
+ * create a Const node with the specified type/typmod.
+ *
+ * This is a convenience routine to create a Const which only the
+ * type is interested but make sure the value is accessible.
+ */
+Const *
+makeDummyConst(Oid consttype, int32 consttypmod, Oid constcollid)
+{
+ int16 typLen;
+ bool typByVal;
+ Const *c;
+ Datum val = 0;
+
+
+ get_typlenbyval(consttype, &typLen, &typByVal);
+
+ if (consttype == NUMERICOID)
+ val = DirectFunctionCall1(numeric_in, CStringGetDatum("0"));
+ else if (!typByVal)
+ elog(ERROR, "create dummy const for type %u is not supported.", consttype);
+
+ /* XXX: here I assume constvalue=0 is accessible for const by value type.*/
+ c = makeConst(consttype, consttypmod, 0, (int) typLen, val, false, typByVal);
+
+ return c;
+}
--