json function volatility

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers