On Fri, Dec 12, 2014 at 10:16:05AM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > 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.
>
> I don't particularly object to having the C code built into the backend;
> there's not that much of it, and if we could static-ize some of the global
> variables that are involved presently, it'd be a Good Thing IMO. However,
> the current arrangement makes sure that the function are not accessible
> except during pg_upgrade, and that seems like a Good Thing as well. So
> I think pg_upgrade should continue to have SQL scripts that create and
> delete the SQL function definitions for these.
Oh, hmmm, would pg_upgrade_support still be a separate shared object
file, or would we just link to functions that already exist in the
backend binary, i.e. it is just the SQL-callabiity you want pg_upgrade
to do?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
