On 12/12/14 10:16 AM, Tom Lane wrote: > 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.
That won't actually work very easily. LANGUAGE internal functions need to be in fmgr_builtins, and the only way to get them there is by listing them in pg_proc.h. (We could drop the functions in initdb, but seems kind of silly.) The functions do already check themselves that they are called in binary upgrade mode, so exposing them in pg_proc doesn't seem risky. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
