Thread: json function volatility

json function volatility

From
Andrew Dunstan
Date:
Following up something Pavel wrote, I notice that json_agg() and 
json_object_agg() are both marked as immutable, even though they invoke 
IO functions, while json_object is marked stable, even though it does 
not, and can probably be marked as immutable. Mea maxima culpa.

I'm not sure what we should do about these things now. Is it a tragedy 
if we let these escape into the 9.4 release that way?

cheers

andrew



Re: json function volatility

From
Merlin Moncure
Date:
On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> Following up something Pavel wrote, I notice that json_agg() and
> json_object_agg() are both marked as immutable, even though they invoke IO
> functions, while json_object is marked stable, even though it does not, and
> can probably be marked as immutable. Mea maxima culpa.
>
> I'm not sure what we should do about these things now. Is it a tragedy if we
> let these escape into the 9.4 release that way?

Is it too late to change them?  Either way, it seems fairly
implausible someone would come up with a case to stick json_agg(), or
any aggregate function really, inside of an index. So it's not exactly
the crime of the century.

merlin



Re: json function volatility

From
Peter Geoghegan
Date:
On Fri, Oct 17, 2014 at 1:44 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> Is it too late to change them?  Either way, it seems fairly
> implausible someone would come up with a case to stick json_agg(), or
> any aggregate function really, inside of an index. So it's not exactly
> the crime of the century.

Indexes reject aggregates outright as acceptable expressions for
indexing. That's not the only issue, of course.

-- 
Peter Geoghegan



Re: json function volatility

From
Alvaro Herrera
Date:
Merlin Moncure wrote:
> On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> > Following up something Pavel wrote, I notice that json_agg() and
> > json_object_agg() are both marked as immutable, even though they invoke IO
> > functions, while json_object is marked stable, even though it does not, and
> > can probably be marked as immutable. Mea maxima culpa.
> >
> > I'm not sure what we should do about these things now. Is it a tragedy if we
> > let these escape into the 9.4 release that way?
> 
> Is it too late to change them?

One thing to consider is the catversion bump, which we don't want this
late in the cycle.  Still, you could change the catalogs but not the
version, and advise those with the older definitions to tweak the
catalogs by hand if they need it.  I think we did this once.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



Re: json function volatility

From
Tom Lane
Date:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Merlin Moncure wrote:
>> On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>> Following up something Pavel wrote, I notice that json_agg() and
>>> json_object_agg() are both marked as immutable, even though they invoke IO
>>> functions, while json_object is marked stable, even though it does not, and
>>> can probably be marked as immutable. Mea maxima culpa.

>>> I'm not sure what we should do about these things now. Is it a tragedy if we
>>> let these escape into the 9.4 release that way?

>> Is it too late to change them?

> One thing to consider is the catversion bump, which we don't want this
> late in the cycle.  Still, you could change the catalogs but not the
> version, and advise those with the older definitions to tweak the
> catalogs by hand if they need it.  I think we did this once.

I'm fairly sure that the system doesn't actually pay attention to the
volatility marking of aggregates, so there's no huge harm done by the
incorrect markings of those.  The incorrect marking of json_object might
be a small optimization block.

+1 for changing these in 9.4 without bumping catversion.  I don't think
we need to give advice for manual corrections, either: the risk of doing
that wrong probably outweighs the value of fixing it.
        regards, tom lane