Re: Constraint stuff (fwd)

On Tue, 8 Aug 2000, Jan Wieck wrote:

> That's not exactly what I said.
>
> PL/Tcl has spi_exec and spi_prepare/spi_execp commands. And
> of course, when the function call's spi_prepare, it is known
> which objects it uses in this one query. But in contrast to
> PL/pgSQL, PL/Tcl could use an argument as a tablename,
> attribute, function, whatnot and build a saved plan for it
> (would need to do so again for each different argument
> value). So it CAN possibly reference almost every object in
> the entire database, and you have no chance to know that,
> even after a hundredthousand invocations of the function.

Okay, that's actually what I had thought, but I wasn't sure after
your previous message. But the saved plans themselves do actually
reference particular objects, even if the function doesn't, right?
So you wouldn't necessarily need to recompile all saved plans,
just ones that reference the changed objects, although it might
be easier to just force all of them.

> And, you're not living isolated in your backend (I know -
> everything would be so easy :-). There's life in other
> processes too, and you need to tell them that they possibly
> have to recompile saved plans for the next Xact. How
> complicated do you want this to be?

Only as complicated as necessary... :) But it seems that it is
necessary to have really functional full set of alter commands.
I mean, if a particular plan references a column whose type has
changed, that sounds like it would be bad to use an old saved plan.
(Oops, that's not a varchar anymore... it's an integer...)

I guess a question is, what is the correct/desired behavior in
certain cases... And what cases are reasonably our problem and what
can we say is the admin's problem? Obviously, we're not going to get
far trying to deal with the possibility that a user changes a column
type and does something that is no longer correct, except to error,
we probably can't and shouldn't fix it, but what things should we handle
automatically?

If you have a function that makes a query like select * from foo that
isn't done via arguments and you rename foo, what *should* happen if
anything? What if you remove it entirely? What about a constraint that
references a function that's renamed, does the constraint follow the name
change? If the function is removed, do we want to remove the now broken
constraint?

Admittedly, the initial thought behind this whole thing was to allow
constraints to properly dump after renames and to make dropping tables or
columns easier to handle for removing referencing constraints (assuming
that we were going to be at some point handling subqueries inside check
constraints). All the rest of this is way past where I initially thought
it to...