Re: Patch: plan invalidation vs stored procedures

The lack of plan invalidation is limitation that also has two bugs attached
to it.
I agree that full fledged patch to fix all the isssues should not be done in
8.3.
I can't agree that effort to get the bugs fixed already in 8.3 should not be
made.
I can understand that hackers here have learned to live with these bugs and
limitations but not all the users are reading these flame wars here and most
of them are not even aware of these bugs until they are hit by them.

Sql function bug is such that users probably won't even understand what hit
them and how the data got mangled.
- If there is nothing that can be done in 8.3 at least warning should be
added into the documentation. It will be just one more don't in our long
list don'ts for our developers.

ERROR: cache lookup failed for function.
- Could the plan be marked as invalid so it would fail only once so the next
call to the function would get replanned and work again. At least it would
be better than losing parts of application for indeterminate time.
- Should update pg_proc set proname = proname; be the current solution to
the problem or has someone something better to offer. We could scan released
code for DROP FUNCTION and generate plan invalidation statement as last item
of transaction releasing the code.
- Could some less dangerous looking mechanism be added to 8.3 that wouldn't
make users not used to PostgreSQL limitations gasp for air when they see the
workarounds :)
Calling the problem limitation will not make it go away. I am quite sure
that new users consider it a bug until thay are converted to perceive it as
lmitation.

No matter how many time the usage of functions in database is called corner
case it does not make it a corner case. In my experience it is quite common
practice on all the database systems i have worked with. I do get the
impression that Tom who would prefer to get all the pl's out of PostgreSQL
and live happily ever after with pure SQL standard.

On Wed, Aug 20, 2008 at 11:27 AM, Dimitri Fontaine
<dfontaine(at)hi-media(dot)com>wrote:

> Le mercredi 20 août 2008, Tom Lane a écrit :
> > That just begs the question of what's the difference between a "bug" and
> > a "limitation". AFAICS, having such a policy/guideline/whatchacallit
> > in place wouldn't have done a single thing to stop the current flamewar,
> > because the people who want this thing back-patched are insisting that
> > it's a bug, while those who don't are saying it's a long-known
> > limitation.
>
> As a person who previously insisted it was a bug, I'd like to take the
> opportunity to claim that I didn't realize this was a limitation of the
> design of plan invalidation, which now seems related to DDL operations.
> Realizing this earlier would have resulted in no mail at all on this thread
> from here.
>
> There's certainly a balance between -hackers readers not doing their
> homework
> and people in the know choosing not to re-estate known things...
>
> > Also, there are a whole lot more considerations in a backpatch decision
> > than just "is it a bug". The (estimated) risk of creating new bugs and
> > the extent to which the patch will change behavior that apps might be
> > relying on are two big reasons why we might choose not to back-patch
> > a bug fix.
>
> And this way the project works is what leads its users not to fear minor
> upgrades, which is something I (we all?) highly value.
>
> Regards,
> --
> dim
>