On Wed, Apr 5, 2017 at 8:57 AM, Peter Eisentraut
<peter.eisentraut@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
