Re: IMMUTABLE and PARALLEL SAFE function markings

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