From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: moving from contrib to bin |
Date: | 2014-12-13 01:43:43 |
Message-ID: | 548B99CF.8030200@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2014-12-13 01:55:21 | Re: moving from contrib to bin |
Previous Message | Tom Lane | 2014-12-13 01:16:03 | Re: operator does not exist: character varying[] <> character[] |