On Wed, Apr 5, 2017 at 8:57 AM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 11/24/16 18:13, Robert Haas wrote: >>> I'm finding hard to imagine a reason why these might be unsafe, but >>> failed. I do notice they're all only used in information_schema. >>> >>> Could it just perhaps be that these just missed the verification >>> process the other functions went through to determine their parallel >>> safety? >> Yes, I think that's it. I went through pg_proc.h, but never looked at >> information_schema.sql. > > This hasn't been fixed yet. It's easy to to, but taking a step back, > > - Is there any reason an immutable function (that is not lying about it) > should be anything but parallel safe?
It certainly isn't very likely. It's not outright impossible. For example, imagine a function that does a calculation which is deterministic given the inputs but which creates and uses temporary tables in the course of performing the calculation. Because the function performs writes, it's parallel-unsafe. > - If so, could CREATE FUNCTION default it that way? This could be done but I'm not sure whether it's wise to make the default value for one parameter depend on another parameter. > - Maybe add a check to opr_sanity to make sure the default set of > functions is configured the way we want? That seems like a good idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers