On Fri, Dec 12, 2014 at 08:11:31AM -0500, Peter Eisentraut wrote:
> On 12/9/14 4:32 PM, Bruce Momjian wrote:
> > On Tue, Dec 9, 2014 at 06:10:02PM -0300, Alvaro Herrera wrote:
> >> (For pg_upgrade you also need to do something about pg_upgrade_support,
> >> which is good because that is one very ugly crock.)
> >
> > FYI, pg_upgrade_support was segregated from pg_upgrade only because we
> > wanted separate binary and shared object build/install targets.
>
> I think the actual reason is that the makefile structure won't let you
> have them both in the same directory. I don't see why you would need
> separate install targets.
>
> How about we move these support functions into the backend? It's not
> like we don't already have other pg_upgrade hooks baked in all over the
> place.
Yes, we can easily do that, and it makes sense. The functions are
already protected to not do anything unless the server is in binary
upgrade mode. If we move them into the backend I think we need to add a
super-user check as well. The reason we don't have one now is that they
are installed/uninstalled by the super-user as part of the pg_upgrade
process.
Moving pg_upgrade out of contrib is going to give me additional gloating
opportunities at conferences. :-)
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
