Re: The missing pg_get_*def functions

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

In response to

Responses

Browse pgsql-hackers by date

  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