Re: Parallel safety tagging of extension functions
От | Tom Lane |
---|---|
Тема | Re: Parallel safety tagging of extension functions |
Дата | |
Msg-id | 7766.1464794138@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parallel safety tagging of extension functions (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: Parallel safety tagging of extension functions
|
Список | pgsql-hackers |
Andreas Karlsson <andreas@proxel.se> writes: > On 06/01/2016 04:44 PM, Tom Lane wrote: >> I don't understand why you think you need the CREATE OR REPLACE FUNCTION >> commands? We only need to change proargtypes, and the updates did that. >> The catcache can take care of itself. > Maybe I did something wrong (I try to avoid doing manual catalog > updates), but when I tested it, I needed to run the CREATE OR REPLACE > FUNCTION command to later be able to set the parallel safety. See the > example below. In this particular example, the problem seems to be that you forgot to update pronargs; it works for me when I add "pronargs = 2" to the UPDATE. Your "working" example is actually creating a new function, not replacing the old pg_proc entry. BTW, it strikes me that the pronamespace tests in these queries are redundant: the OID is unique, so what matters is the search path in the regprocedure lookups. > The reason I use to_regprocedure is so that these scripts work for > people who have installed the extensions in beta1 and therefore only > have the new signatures. If they run these scripts they would get an > error if I used the cast. Is it ok if these scripts break for beta1 users? Ugh. This is more of a mess than I thought. I don't like update scripts that might silently fail to do what they're supposed to, but leaving beta1 users in the lurch is not very nice either. I wonder ... could we get away with using regproc rather than regprocedure? These function names are probably unique anyway ... regards, tom lane
В списке pgsql-hackers по дате отправления: