Re: [PATCHES] Updatable views

Bernd Helmle <bernd(dot)helmle(at)oopsware(dot)de> writes:
> I would like to try to grab your idea to push down the CHECK OPTION logic
> down to the executor as a (table/view?) constraint. Would that be an idea
> worth to consider and,
> most important, is this doable? I don't have that much experience in the
> executor, so i fear
> this isn't something that will be done within a week or so.....:(

You're certainly welcome to work on it --- I don't have time at the
moment. But I agree there's little chance of getting it done in time
for 8.2.

I have not read the spec's definition of WITH CHECK OPTION lately, so
there may be something fundamentally wrong in what I'm about to say,
but the way I'm envisioning this working is that W.C.O. is embodied as
a check constraint (or something pretty similar --- a pg_constraint
entry certainly) attached to the view. The rewriter would then be
responsible for collecting all the check options that need to be
enforced for a given rewritten query. This'd require some rework of
the rewriter/planner/executor API: right now the executor is solely
responsible for collecting check constraints to apply in an updating
query, and we'd want to change that. My thought is we might as well
move the collection responsibility over to the rewriter 100%: the
rewriter decorates a Query with the list of constraint expressions
to apply, and the executor just checks what it's told to. The planner
probably need not do much with the constraint expressions beyond what
it normally does with, say, targetlist expressions.

Some thoughts:

* It's too early in the morning for me to be clear about the difference
between CASCADED and LOCAL CHECK OPTION --- I think that this would
merely alter the set of check constraints collected for a particular
query, but if there's something more fundamental there, this scheme
might not work at all. So look into that first.

* The reason we currently collect constraints at executor start is that
ALTER TABLE ADD CONSTRAINT has no way to invalidate cached plans, so
it's unsafe to store lists of constraints in plans. So this scheme
*requires* that we have a plan invalidation mechanism in place (at least
before we release, maybe not before the patch can go in). This doesn't
bother me because I intend anyway to see to it that there's plan inval
in 8.3.

* With check constraints now passing through the planner, it'd become
trivial to allow subqueries in check constraints. Just sayin'.

* We'd probably eliminate the idea of storing constraints in TupleDescs,
which would be a good simplification anyway (eg, eliminate the bogus
distinction between CreateTupleDescCopy and CreateTupleDescCopyConstr).
OTOH that might make it harder to allow rowtypes to have associated
constraints? Needs thought.

regards, tom lane