Re: [bug?] Missed parallel safety checks, and wrong parallel safety
От | Greg Nancarrow |
---|---|
Тема | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
Дата | |
Msg-id | CAJcOf-cyxsSKT4eTOUmOCZyNCRFJ+dkFPN2BW7pRFiHrNO1WuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [bug?] Missed parallel safety checks, and wrong parallel safety (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [bug?] Missed parallel safety checks, and wrong parallel safety
|
Список | pgsql-hackers |
On Wed, May 5, 2021 at 5:09 AM Robert Haas <robertmhaas@gmail.com> wrote: > > On Fri, Apr 23, 2021 at 10:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > Isn't parallel safety also the C code property? > > > Also, if the strict property of built-in functions is fixed > > internally, why we allow users to change it and is that of any help? > > One real application of allowing these sorts of changes is letting > users correct things that were done wrong originally without waiting > for a new major release. > Problem is, for built-in functions, the changes are allowed, but for some properties (like strict) the allowed changes don't actually take effect (this is what Amit was referring to - so why allow those changes?). It's because some of the function properties are cached in FmgrBuiltins[] (for a "fast-path" lookup for built-ins), according to their state at build time (from pg_proc.dat), but ALTER FUNCTION is just changing it in the system catalogs. Also, with sufficient privileges, a built-in function can be redefined, yet the original function (whose info is cached in FmgrBuiltins[]) is always invoked, not the newly-defined version. Regards, Greg Nancarrow Fujitsu Australia
В списке pgsql-hackers по дате отправления: