Re: The missing pg_get_*def functions

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

In response to

Browse pgsql-hackers by date

  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