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

From Pavel Stehule
Subject Re: Patch: plan invalidation vs stored procedures
Date
Msg-id 162867790808191048k1e126e58o9ba7567ed09d89f5@mail.gmail.com
Whole thread Raw
In response to Re: Patch: plan invalidation vs stored procedures  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: Patch: plan invalidation vs stored procedures  ("Asko Oja" <ascoja@gmail.com>)
List pgsql-hackers
2008/8/19 Dimitri Fontaine <dfontaine@hi-media.com>:
> Le mardi 19 août 2008, Tom Lane a écrit :
>> [ shrug... ] You have not found a bug in plan invalidation.  You have
>> found omitted functionality --- functionality that was *intentionally*
>> omitted from the 8.3 version.
>
> Thanks a lot for this clarification, now I understand you viewpoint.
>
> So, the 8.3 "fix" would be about documenting this intentionnal omit in the
> great manual, maybe in a Limits section of the sql-createfunction page?
>
> 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
> project here where the project manager wants a database function API to keep
> data logic at serverside, should I tell him to reconsider this while 8.4 is
> not ready?

You could to use patched 8.3.

> We would then have to go live with an 8.3 based solution containing middleware
> code, then port it again to SQL functions when 8.4 is out & stable. Not
> appealing, but I sure understand the no new feature in stable code base
> argument here.

This problem isn't too hard without pooling. Not all systems are
global - so usually is possible to find some window and recreate
functions and close all user connections.

Regards
Pavel Stehule

>
> Regards,
> --
> dim
>

pgsql-hackers by date:

Previous
From: "Asko Oja"
Date:
Subject: Re: Patch: plan invalidation vs stored procedures
Next
From: "Asko Oja"
Date:
Subject: Re: Patch: plan invalidation vs stored procedures