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

From Asko Oja
Subject Re: Patch: plan invalidation vs stored procedures
Date
Msg-id ecd779860808191057t1d64716vfeffacd46c913662@mail.gmail.com
Whole thread Raw
In response to Re: Patch: plan invalidation vs stored procedures  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: Patch: plan invalidation vs stored procedures  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
> 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.
People are expected to use same workarounds as Skype is using. For us another unneccessary downtime week ago was what set us moving/thinking :). When you use software with limitations then you learn to live with them. Good thing about postgres you can do something yourself to get some of the limitations removed.
As Pavel said you are probably using your own build anyway so one more patch should not be a problem.

regards
Asko

On Tue, Aug 19, 2008 at 8:48 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
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
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: Patch: plan invalidation vs stored procedures
Next
From: Magnus Hagander
Date:
Subject: Re: temporary statistics option at initdb time