Re: The missing pg_get_*def functions
От | Andrew Dunstan |
---|---|
Тема | Re: The missing pg_get_*def functions |
Дата | |
Msg-id | 517F9B54.3040306@dunslane.net обсуждение исходный текст |
Ответ на | Re: The missing pg_get_*def functions (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: The missing pg_get_*def functions
Re: The missing pg_get_*def functions |
Список | 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 по дате отправления: