Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4

Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)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