Re: Extract numeric filed in JSONB more effectively - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Extract numeric filed in JSONB more effectively
Date
Msg-id CAKU4AWoLgC5ejOF8jxskd5oq52D-eR_1Q-HM5+e8OBVLak=qTg@mail.gmail.com
Whole thread Raw
In response to Re: Extract numeric filed in JSONB more effectively  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: Extract numeric filed in JSONB more effectively
List pgsql-hackers



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;
+}

--
Best Regards
Andy Fan
Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Next
From: "Bagga, Rishu"
Date:
Subject: Re: SLRUs in the main buffer pool - Page Header definitions