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...