As suggested, I intend to create a 'CoerceToDomain' node in the
expression tree rather than attempting to apply the create the
constraints tests immediately.

1. Create a new function in the executor to handle domain coercions:
ExecEvalCoerceToDomain()

2. Move coerce_type_constraints to the executor (builds expression tree
of constraints) under the name ExecCoerceTypeConstraints().

3. On initial pass, CoerceToDomain will have a 'raw' expression tree
(simple arg of data to coerce).  After passing through
ExecCoerceTypeConstraints a 'cooked' expression tree will contain the
constraint tests.  Subsequent tuples will simply use the pre-cooked
tree.


-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
17 Dec 2002 14:45:11 -0500
Rod Taylor <rbt@rbt.ca>
Coerce to Domain
Rod Taylor <rbt@rbt.ca> writes:
> 3. On initial pass, CoerceToDomain will have a 'raw' expression tree
> (simple arg of data to coerce).  After passing through
> ExecCoerceTypeConstraints a 'cooked' expression tree will contain the
> constraint tests.

Uh ... why?  The cooked tree should be stored in pg_constraint, no?
What's the point of redoing the parse analysis phase?

BTW, this should be a lot easier to do cleanly (ie, without memory
leaks) now that there's a notion of expression state trees.  You can
attach the information loaded from pg_constraint to the expression state
node for the CoerceToDomain node (being careful to copy it into
estate->es_query_cxt).  Maybe that was already apparent to you ...

			regards, tom lane

Tue, 17 Dec 2002 18:15:54 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Coerce to Domain 
On Tue, 2002-12-17 at 18:15, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> > 3. On initial pass, CoerceToDomain will have a 'raw' expression tree
> > (simple arg of data to coerce).  After passing through
> > ExecCoerceTypeConstraints a 'cooked' expression tree will contain the
> > constraint tests.
> 
> Uh ... why?  The cooked tree should be stored in pg_constraint, no?
> What's the point of redoing the parse analysis phase?

Ok.. Cooked was the wrong word.  The individual constraints will not be
retested, but the group as a whole will be prepared (discovered?, looked
up?).

> node for the CoerceToDomain node (being careful to copy it into
> estate->es_query_cxt).  Maybe that was already apparent to you ...

Somewhat apparent given your recent commits.  I've not looked to find
out exactly what it is yet, but I'm guessing recent changes to
EvalPlanQual() will tell me.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
17 Dec 2002 19:18:14 -0500
Rod Taylor <rbt@rbt.ca>
Re: Coerce to Domain
Rod Taylor <rbt@rbt.ca> writes:
> Somewhat apparent given your recent commits.  I've not looked to find
> out exactly what it is yet, but I'm guessing recent changes to
> EvalPlanQual() will tell me.

Don't look at EvalPlanQual() ... you'll just get confused ;-).
It's a mess, and not related to constraints.

The code around init_fcache and ExecEvalFunc might be more enlightening
for your immediate purposes.

			regards, tom lane

Tue, 17 Dec 2002 19:23:59 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Coerce to Domain 