From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
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 13:08:15 |
Message-ID: | m2k3ncp874.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> 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
In case it wasn't clear, I agree with your view here and consider the
capability to auto-upgrade extensions a must have. What I say is that if
you ship the .so part of an extension in a live system, the next backend
that starts will use that code, without a restart.
That does not allow us not to provide a way to force-reload modules
currently used in live backends, and we still need to be able to upgrade
the system catalogs and "extension catalogs" too, either at startup in
live operations.
Separating away some code and SQL into in-core installed-by-default
extensions means we have new problems and abilities, not that some
problem are solved by themselves.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Vincenzo Melandri | 2013-05-06 13:30:03 | about index inheritance |
Previous Message | Bruce Momjian | 2013-05-06 12:59:56 | Re: 9.3 release notes suggestions |