Peter Eisentraut <pete...@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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
