I wrote:
> I'd prefer not to have ExecPrepareExpr do it, though; that's supposed
> to be working from a read-only expression tree supplied by the caller.
> (The fix_opfuncids call in it is already pushing the bounds of that
> concept.)
> From a structural point of view the right thing would be to introduce
> a concept of "expression planning", along the lines of
> expr = plan_expression(expr);
> which callers would be required to invoke before ExecPrepareExpr.
> Right now this would do the fix_opfuncids bit and
> eval_const_expressions, but I could see someday allowing SubLinks
> in standalone expressions because we'd have the ability to invoke
> the full planner from inside here.
I looked around and found that the main issue with doing it the way
I was envisioning is the ii_Expressions and ii_Predicate expression
trees in struct IndexInfo. I wanted to run those trees through
plan_expression() before sticking them into IndexInfo, but the trouble
with that approach is that in UpdateIndexRelation() we expect that we
can use nodeToString() on them to produce the index definitional data
that will get stored into pg_index. We do *not* want to use "planned"
expressions for that --- it would cause function defaults to propagate
into the index definition, which is exactly what we are trying to avoid
by not inserting defaults until plan time.
So it seems like the best solution is to allow ExecPrepareExpr to
call plan_expression(). A look through the callers suggests that
this won't really result in much repeated work because there are few
cases where the results could be re-used anyway. It's still a tad
annoying, but not enough so to justify a lot of code rearrangement
right now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
