(Aside: I have so many problems with PostgreSQL’s “::” operator. It is not just a cast, or object-oriented. It is object-oriented as implemented by C++, circa 1995. Since C++ didn’t have gc, all of the object-oriented goodness was muddied with the demands of stack-based memory allocation, constructors and destructors. The semantics are downright weird to anyone who doesn’t come from that culture.)
In this case, 'mytable'::regclass is a call to the constructor of the regclass type that takes a string argument. Calcite supports user-defined types[1], but we don’t talk about them very often, and we don’t use PostgreSQL’s non-standard ‘::’ syntax. I think modeling regclass as a type make sense, and then we can generate SQL to look up an instance given a string. I don’t know how that would turn into code, but at least we would be using the same mechanism that PostgreSQL is using. Julian [1] https://issues.apache.org/jira/browse/CALCITE-2045 > On Feb 26, 2019, at 7:58 AM, Michael Mior <[email protected]> wrote: > > There's no direct connection between the parser and the planner, so > you'll have to configure the rule sets yourself based on the parser > you're using. You could use a second rule, although you might also try > avoiding rules altogether and just using RelNode#accept on the root > node of your query and use the RexShuttle implementation to visit > every RexNode which should cover both cases. > > -- > Michael Mior > [email protected] > > Le mar. 26 févr. 2019 à 10:50, Muhammad Gelbana <[email protected]> a écrit > : >> >> I believe >> org.apache.calcite.prepare.CalcitePrepareImpl.createPlanner(Context, >> Context, RelOptCostFactory) is the correct location to add my rule(s). But >> since this should only run when the praser is Babel, I tried to find that >> information from within the mentioned method (*createPlanner*) but I >> couldn't. Am I missing something or should I pass through such information >> to the *createPlanner* method ? >> >> Another thing, the expression may be in a "Project" too (i.e. SELECT >> typname::regproc FROM pg_catalog.pg_type WHERE typname LIKE 'bool') >> I suppose I'll have to have 2 rules. One for Project and another for Filter. >> >> Thanks, >> Gelbana >> >> >> On Tue, Feb 26, 2019 at 4:12 PM Michael Mior <[email protected]> wrote: >> >>> Writing a rule would certainly work. You would want to match a Filter >>> RelNode and then perhaps use an implementation of RexShuttle on the >>> condition and implement visitCall to check for appropriate casts to be >>> transformed into the subquery you want using RexSubQuery.scalar to >>> generate the new query. >>> >>> -- >>> Michael Mior >>> [email protected] >>> >>> Le mar. 26 févr. 2019 à 05:55, Muhammad Gelbana <[email protected]> a >>> écrit : >>>> >>>> I'm willing to implement running PostgreSQL queries involving OID casts >>>> >>>> *For example:* >>>> SELECT * FROM pg_attribute >>>> WHERE attrelid = 'mytable'::regclass; >>>> >>>> *Should be executed as:* >>>> SELECT * FROM pg_attribute >>>> WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable'); >>>> >>>> Note that *reglass* maps to the *pg_class* table. >>>> >>>> What is the "calcite way" to implement this ? Should I write a rule ? >>>> Or should I rewrite the query before implementing it (I'm not sure where >>> is >>>> that) ? >>>> >>>> Thanks, >>>> Gelbana >>>
