Re: The missing pg_get_*def functions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: The missing pg_get_*def functions
Date
Msg-id 517F9B54.3040306@dunslane.net
Whole thread Raw
In response to Re: The missing pg_get_*def functions  (Joel Jacobson <joel@trustly.com>)
Responses Re: The missing pg_get_*def functions
Re: The missing pg_get_*def functions
List 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



pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: Graph datatype addition
Next
From: Simon Riggs
Date:
Subject: Re: Substituting Checksum Algorithm (was: Enabling Checksums)