From: Tom Lane <t...@sss.pgh.pa.us>
> Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> writes:
> > IMO, the reason for not checking the parallel safety of the support
> > functions is that the functions themselves can have whole lot of other
> > functions (can be nested as well) which might be quite hard to check
> > at the planning time. That is why the job of marking an aggregate as
> > parallel safe is best left to the user.
>
> Yes. I think the documentation is perfectly clear that this is
> intentional; I don't see a need to change it.
OK, that's what I expected. I understood from this that the Postgres's stance
toward parallel safety is that Postgres does its best effort to check parallel
safety (as far as it doesn't hurt performance much, and perhaps the core code
doesn't get very complex), and the user should be responsible for the actual
parallel safety of ancillary objects (in this case, support functions for an
aggregate) of the target object that he/she marked as parallel safe.
> >> Should we add a member for parallel safety in fmgr_builtins[], and disallow
> ALTER FUNCTION to change the parallel safety of builtin UDFs?
>
> No. You'd have to be superuser anyway to do that, and we're not in the
> habit of trying to put training wheels on superusers.
Understood. However, we may add the parallel safety member in fmgr_builtins[]
in another thread for parallel INSERT SELECT. I'd appreciate your comment on
this if you see any concern.
> Don't have an opinion about the other points yet.
I'd like to have your comments on them, too. But I understand you must be so
busy at least until the beta release of PG 14.
Regards
Takayuki Tsunakawa
