Thread: Finishing Domains...

Finishing Domains...

From
Rod Taylor
Date:
I've got a couple of free days coming up, so I want to finish domain
support (Check constraints).

Is it safe to teach Var how to deal with values that do not originate
from a tuple?  Or should I create a new primnode to deal with these
types of variables.


CREATE DOMAIN dom AS integer CHECK(VALUE BETWEEN 6 AND 10);

SELECT CAST(8 AS dom);



--  Rod Taylor



Re: Finishing Domains...

From
Tom Lane
Date:
Rod Taylor <rbt@rbt.ca> writes:
> Is it safe to teach Var how to deal with values that do not originate
> from a tuple?  Or should I create a new primnode to deal with these
> types of variables.

I have no idea what you're talking about, but it sure sounds like
something that should not be in Var ... perhaps you ought to post a
more complete design document before you start coding.
        regards, tom lane


Re: Finishing Domains...

From
Rod Taylor
Date:
On Mon, 2002-11-04 at 09:44, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> > Is it safe to teach Var how to deal with values that do not originate
> > from a tuple?  Or should I create a new primnode to deal with these
> > types of variables.
> 
> I have no idea what you're talking about, but it sure sounds like
> something that should not be in Var ... perhaps you ought to post a
> more complete design document before you start coding.

Sorry, had planned on it.  Anyway, below is a summary of what I think I
need to do.


Goal:
CREATE DOMAIN dom AS integer CHECK(VALUE = 4 OR VALUE = 10);                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The constraint will be stored in pg_constraint with the conrelid set to
0, and contypid set to the domain pg_type oid.  Domain check constraints
will be pulled out of the table and inserted into the executor tree in
coerce_type_constraints(), for execution by ExecEvalConstraintTest().


In the parser, I intend to represent the 'VALUE' term by a
DomainConstraintValue node which inherits the properties (TypId, TypMod)
of the domain base type.  Requires some muckary in transformExpr() to
carry the current datatype through it, much like carrying a context
through the executor.


It has been mentioned a few times that parse nodes should not be used in
the executor as they tend to be bug prone, so I don't want to use
DomainConstraintValue in the executor.  So, I need a way to represent
VALUE in both the stored pg_constraint.conbin column and the executor,
which is replaced with the Datum being operated on during
ExecEvalConstraintTest().

The Datum is created in ExecEvalConstraintTest, so it's easy to add it
to the local context, and call ExecEvalExpr on the (VALUE = 4 OR VALUE =
10) expression. ExecEvalExpr runs through the Node passed and fills in
subexpressions (Var nodes for example).

Do I teach ExecEvalVar how to pull out an arbitrary value from
ExprContext (since this is technically a variable), or do I create a
different 'Var' for managing variables which do not come in the Tuple
format.  All I need is the datatype, and a little knowledge of the
variable thats in ExprContext.

--  Rod Taylor