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 >
