Re: Patch: plan invalidation vs stored procedures

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: plan invalidation vs stored procedures
Date: 2008-08-19 19:26:09
Message-ID: 76CBE020-FBE1-4019-AF95-9043A2721810@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Le 19 août 08 à 19:06, Tom Lane a écrit :
> Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
>> 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.
>
> What we've got at this point is a submitted patch for a new feature
> that hasn't even been accepted into HEAD yet. Lobbying to get it
> back-patched is entirely inappropriate IMHO.

Well, there's a misunderstanding here. I certainly were lobbying for
considering a backpatch as I saw it as a bugfix. You told me it's a
new feature, I say ok for not backpatching, obviously.

This mail was a real attempt at learning some tips to be able to push
the functions usage as far as Skype is doing, in 8.3 release, and
avoiding the trap which has always existed in released PostgreSQL
version. This certainly was a bad attempt at it.

Now, my understanding is that rolling out new versions of functions
requires forcing dropping all current opened sessions as soon as
PostgreSQL considers you need to drop any function. I'll think about
it in next project design meetings.

Regards,
- --
dim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkirHlEACgkQlBXRlnbh1bk4YQCgswDS1bu+P+N7yKJvwnRAWnL3
FYkAnRZQzqbEoahShh/Qz9mnrIm1e99y
=hIBt
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2008-08-19 19:32:29 Re: Patch: plan invalidation vs stored procedures
Previous Message Joshua Drake 2008-08-19 19:21:17 Re: A smaller default postgresql.conf