Re: Patch: plan invalidation vs stored procedures - Mailing list pgsql-hackers

<div dir="ltr">The lack of plan invalidation is limitation that also has two bugs attached to it.<br />I agree that
fullfledged patch to fix all the isssues should not be done in 8.3. <br />I can't agree that effort to get the bugs
fixedalready in 8.3 should not be made.<br /> I can understand that hackers here have learned to live with these bugs
andlimitations but not all the users are reading these flame wars here and most of them are not even aware of these
bugsuntil they are hit by them. <br /><br />Sql function bug is such that users probably won't even understand what hit
themand how the data got mangled.<br />- If there is nothing that can be done in 8.3 at least warning should be added
intothe documentation.  It will be just one more don't in our long list don'ts for our developers.<br /><br />ERROR: 
cachelookup failed for function. <br />- Could the plan be marked as invalid so it would fail only once so the next
callto the function would get replanned and work again. At least it would be better than losing parts of application
forindeterminate time. <br /> - Should update pg_proc set proname = proname; be the current solution to the problem or
hassomeone something better to offer. We could scan released code for DROP FUNCTION and generate plan invalidation
statementas last item of transaction releasing the code.<br /> - Could some less dangerous looking mechanism be added
to8.3 that wouldn't make users not used to PostgreSQL limitations gasp for air when they see the workarounds :)<br
/>Callingthe problem limitation will not make it go away. I am quite sure that new users consider it a bug until thay
areconverted to perceive it as lmitation.<br /><br />No matter how many time the usage of functions in database is
calledcorner case it does not make it a corner case. In my experience it is quite common practice on all the database
systemsi have worked with. I do get the impression that Tom who would prefer to get all the pl's out of PostgreSQL and
livehappily ever after with pure SQL standard. <br /><br /><div class="gmail_quote">On Wed, Aug 20, 2008 at 11:27 AM,
DimitriFontaine <span dir="ltr"><<a href="mailto:dfontaine@hi-media.com">dfontaine@hi-media.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left:1ex;"> Le mercredi 20 août 2008, Tom Lane a écrit :<br /><div class="Ih2E3d">> That just begs the
questionof what's the difference between a "bug" and<br /> > a "limitation".  AFAICS, having such a
policy/guideline/whatchacallit<br/> > in place wouldn't have done a single thing to stop the current flamewar,<br />
>because the people who want this thing back-patched are insisting that<br /> > it's a bug, while those who don't
aresaying it's a long-known<br /> > limitation.<br /><br /></div>As a person who previously insisted it was a bug,
I'dlike to take the<br /> opportunity to claim that I didn't realize this was a limitation of the<br /> design of plan
invalidation,which now seems related to DDL operations.<br /> Realizing this earlier would have resulted in no mail at
allon this thread<br /> from here.<br /><br /> There's certainly a balance between -hackers readers not doing their
homework<br/> and people in the know choosing not to re-estate known things...<br /><div class="Ih2E3d"><br /> >
Also,there are a whole lot more considerations in a backpatch decision<br /> > than just "is it a bug".  The
(estimated)risk of creating new bugs and<br /> > the extent to which the patch will change behavior that apps might
be<br/> > relying on are two big reasons why we might choose not to back-patch<br /> > a bug fix.<br /><br
/></div>Andthis way the project works is what leads its users not to fear minor<br /> upgrades, which is something I
(weall?) highly value.<br /><br /> Regards,<br /><font color="#888888">--<br /> dim<br /></font></blockquote></div><br
/></div>