From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Joel Jacobson <joel(at)trustly(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The missing pg_get_*def functions |
Date: | 2013-04-30 10:22:12 |
Message-ID: | 517F9B54.3040306@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/29/2013 11:47 PM, Joel Jacobson wrote:
>> Note also that minor releases can readily fix bugs in C-language functions,
>> but we have no infrastructure to update sql-language functions after initdb.
>> That flexibility is unfortunate to lose, particularly for something that
>> pg_dump depends on. Now, the right thing is probably to design a mechanism
>> for applying simple catalog updates in concert with a minor release. In the
>> mean time, its absence puts the sql PL at a nontrivial disadvantage here.
> What do you mean with "infrastructure"? Isn't it as simple as CREATE
> OR REPLACE FUNCTION? As long as the interface the pg_get_*def
> functions don't change, I cannot see how simply replacing the existing
> functions in a minor release upgrade could do any harm.
>
Minor releases are supposed not to require any such operations. You
should normally be able to drop the binaries in place and restart. For C
language functions that is indeed all you have to do, but that's not the
case for SQL language functions, where the definition is contained in
the catalogs, not the binary.
If all you want is SQL language functions, there is nothing to stop you
from writing them and publishing them today as an extension.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2013-04-30 10:55:29 | Re: Substituting Checksum Algorithm (was: Enabling Checksums) |
Previous Message | Atri Sharma | 2013-04-30 08:59:13 | Re: Graph datatype addition |