Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> I'd also like to mention still our C-trigger..... :
> - it starts of with three plan variables containing '0' and it uses
> SPI_saveplan() to fill these with a cached plan
> - the three underlying tables will never change structure during such a
> session, so I expected these variables / plans to never change
> - if these static SPIPlanPtr variables are non-zero, the cached plans will be
> reused in a SPI_execute_plan() call
> Now the docs of SPI_saveplan say the following:
> "If one of the objects (a table, function, etc.) referenced by the prepared
> plan is dropped or redefined, then future executions of SPI_execute_plan may
> fail or return different results than the plan initially indicates. "
> Given the fact that 8.4 invalidates plans much more often, this might become
> tricky..... the 'SPI_execute_plan may fail' part can be handled, but I'm a bit
> worried about the 'may return different results' part..... Is there a way to
> determine (efficiently) that such a save plan has been invalidated?
You don't need to worry about that as long as you're not changing the
table's DDL in a way that would affect the query result. It's entirely
possible for the plan to get invalidated and regenerated underneath you,
but that should be invisible to a SPI caller.
regards, tom lane
