On Tue, May 4, 2021 at 11:47 PM Greg Nancarrow <gregn4...@gmail.com> wrote: > 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.
I agree. I think that's not ideal. I think we should consider putting some more restrictions on updating system catalog changes, and I also think that if we can get out of having strict need to be part of FmgrBuiltins[] that would be good. But what I don't agree with is the idea that since strict already has this problem, it's OK to do the same thing with parallel-safety. That seems to me to be making a bad situation worse, and I can't see what problem it actually solves. -- Robert Haas EDB: http://www.enterprisedb.com
