Re: Patch: plan invalidation vs stored procedures

> Another thing I do not understand well is how people are expected to work in
> 8.3 with a function based API, without hitting Skype problems. I'm having a

All database-driven applications have this problem. Any time you have
a database on the backend and interface code on the front-end, you
need to keep in mind that it won't necessarily be possible to update
the two of them simultaneously, especially if you have multiple
back-ends and multiple front-ends, as you almost certainly do. Even
if PostgreSQL invalidated plans in the particular situation you're
discussing, there would still be other problems. You could add a new,
non-NULLable column to a table before updating the code that insert
into that table, or drop an old column that the code still counts on
being able to access.

I handle these problems all the time by ordering the changes
carefully. If I need to change a function API in an incompatible way,
I change the NAME of the function as well as the type signature (eg.
do_important_thing -> do_important_thing_v2). Then I change the code.
Then I remove the old function once everything that relies on it is
dead.

Maybe in your particular environment plan invalidation for functions
will solve most of the cases you care about, but I respectfully submit
that there's no substitute for good release engineering. If you don't
know exactly what functions are going to be created, modified, or
dropped on your production servers during each release before you
actually roll that release out... you probably need to improve your
internal documentation.

...Robert