From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The missing pg_get_*def functions |
Date: | 2013-05-06 12:45:38 |
Message-ID: | 20130506124538.GD4361@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)fr) wrote:
> Another advantage of using more the extension infrastructure is that
> shipping bug fixes in the C or SQL parts of them would allow a hot fix
> to be shipped without restart when limited to an extension.
I'm actually not thrilled with the security update situation when it
comes to extensions. It really is a disservice to our users to ask them
to independently manage each and every extension and upgrade each one of
them by hand.
> In-core installed-by-default extensions, anyone?
I'm not against this idea- but we *still* need to solve the problem of
how we update the catalog during a point release and, imv anyway, we
would need to be able to upgrade any in-core installed-by-default
extensions during a point release too, to address any security or other
issues from them. Right now we get to slide by on upgrading extensions
by not having any in-core / installed-by-default ones and punting to the
user with "well, you installed it, not us, therefore you have to manage
it by hand for eternity"; that doesn't work when we're installing it for
them and they may not even know they've got it..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-05-06 12:52:50 | Re: The missing pg_get_*def functions |
Previous Message | Dimitri Fontaine | 2013-05-06 12:34:52 | Re: The missing pg_get_*def functions |