On 2018-11-27 00:47:47 +0100, Vik Fearing wrote: > On 27/11/2018 00:39, Andres Freund wrote: > > Hi, > > > > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote: > >> On 26/11/2018 22:23, Gajus Kuizinas wrote: > >>> I was wondering what is the reason IMMUTABLE functions are not by > >>> default PARALLEL SAFE and if the default behaviour could be changed to > >>> make IMMUTABLE functions PARALLEL SAFE? > >> > >> I think I have to concur with this. When is an immutable function not > >> parallel safe? > >> > >> Sure it could be mislabeled as immutable but it could just as easily be > >> mislabeled as parallel safe. And we already treat fake immutable > >> functions as user errors, for example in indexes. > > > > I think it'd introduce more problems than it'd solve. Either you ignore > > the proparallel setting - resulting in broken catalog querying - or you > > have to have a decent amount of special behaviour that an explicit ALTER > > FUNCTION ... IMMUTABLE | STABLE | VOLATILE and SET PARALLEL { UNSAFE > > | RESTRICTED | SAFE } would also need to change the respective other > > category. > > Surely a simple rule could be made that provolatile='i' trumps > proparallel. No need to make them agree. > > The default catalogs should agree (and I would expect the sanity checks > to look for that) but here we're talking about user functions.
I think it'd be entirely unacceptable that SELECT * FROM pg_proc WHERE proparallel = 's' wouldn't actually return all the functions that are parallel safe. Greetings, Andres Freund