Why are JSON extraction functions STABLE and not IMMUTABLE?

On 04/15/2013 11:16 AM, hubert depesz lubaczewski wrote:

In current 9.3, I see:

$ select p.proname, p.provolatile from pg_proc p join pg_namespace n on p.pronamespace = n.oid where n.nspname = 'pg_catalog' and p.proname ~ 'json';
proname | provolatile
---------------------------+-------------
json_in | s
json_out | i
json_recv | s
json_send | s
array_to_json | s
array_to_json | s
row_to_json | s
row_to_json | s
json_agg_transfn | i
json_agg_finalfn | i
json_agg | i
to_json | s
json_object_field | s
json_object_field_text | s
json_array_element | s
json_array_element_text | s
json_extract_path | s
json_extract_path_op | s
json_extract_path_text | s
json_extract_path_text_op | s
json_array_elements | s
json_array_length | s
json_object_keys | s
json_each | s
json_each_text | s
json_populate_record | s
json_populate_recordset | s
(27 rows)

Is there any particular reason extract functions
(object_field/array_element/...) can't be immutable?

I can't readily imagine a situation where output of these functions would
change for different queries.

Me either. It's an oversight, really. Unless there is any objection I'll
change them toot sweet. What about the existing (as of 9.2) functions?

cheers

andrew

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

On Mon, Apr 15, 2013 at 11:31:39AM -0400, Andrew Dunstan wrote:

Me either. It's an oversight, really. Unless there is any objection
I'll change them toot sweet. What about the existing (as of 9.2)
functions?

I don't think that 9.2 functions are that interesting, since these are
to build json values, and as such are not really candidates to making
index off.

Best regards,

depesz

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

Andrew Dunstan <andrew@dunslane.net> writes:

Is there any particular reason extract functions
(object_field/array_element/...) can't be immutable?

I can't readily imagine a situation where output of these functions would
change for different queries.

Me either. It's an oversight, really. Unless there is any objection I'll
change them toot sweet. What about the existing (as of 9.2) functions?

Note that anything that invokes other types' I/O functions can't be
immutable, at most stable. But the ones that don't do that certainly
should be fixed.

BTW, while I'm looking at this: json_populate_record and
json_populate_recordset are marked as non-strict, but they are
completely broken for null inputs because they attempt to fetch inputs
before checking them for null-ness.

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

On 2013-04-15 11:31:39 -0400, Andrew Dunstan wrote:

On 04/15/2013 11:16 AM, hubert depesz lubaczewski wrote:

In current 9.3, I see:

$ select p.proname, p.provolatile from pg_proc p join pg_namespace n on p.pronamespace = n.oid where n.nspname = 'pg_catalog' and p.proname ~ 'json';
proname | provolatile
---------------------------+-------------
json_in | s
json_out | i
json_recv | s
json_send | s
array_to_json | s
array_to_json | s
row_to_json | s
row_to_json | s
json_agg_transfn | i
json_agg_finalfn | i
json_agg | i
to_json | s
json_object_field | s
json_object_field_text | s
json_array_element | s
json_array_element_text | s
json_extract_path | s
json_extract_path_op | s
json_extract_path_text | s
json_extract_path_text_op | s
json_array_elements | s
json_array_length | s
json_object_keys | s
json_each | s
json_each_text | s
json_populate_record | s
json_populate_recordset | s
(27 rows)

Is there any particular reason extract functions
(object_field/array_element/...) can't be immutable?

I can't readily imagine a situation where output of these functions would
change for different queries.

Me either. It's an oversight, really. Unless there is any objection I'll
change them toot sweet. What about the existing (as of 9.2) functions?

ISTM json_in, out, recv, send should also be immutable. array_to_json,
row_to_json et all can't be tho.

Greetings,

Andres Freund

--
Andres Freund 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

On 04/15/2013 11:46 AM, Andres Freund wrote:

Me either. It's an oversight, really. Unless there is any objection I'll
change them toot sweet. What about the existing (as of 9.2) functions?

ISTM json_in, out, recv, send should also be immutable. array_to_json,
row_to_json et all can't be tho.

OK, although these have been like this since 9.2. I'm not sure why
json_out is immutable but json_in isn't.

Does changing these require a catalog version bump?

cheers

andrew

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

Andrew Dunstan <andrew@dunslane.net> schrieb:

On 04/15/2013 11:46 AM, Andres Freund wrote:

Me either. It's an oversight, really. Unless there is any objection

I'll

change them toot sweet. What about the existing (as of 9.2)

functions?

ISTM json_in, out, recv, send should also be immutable.

array_to_json,

row_to_json et all can't be tho.

OK, although these have been like this since 9.2. I'm not sure why
json_out is immutable but json_in isn't.

Does changing these require a catalog version bump?

Well, you could get away without one since a more permissive value should only influence performance and not correctness. But there doesn't yet seem much reason to avoid it that much yet. It could cause confusion for someone at some point.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

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

On Mon, Apr 15, 2013 at 04:41:53PM -0400, Andrew Dunstan wrote:

On 04/15/2013 11:46 AM, Andres Freund wrote:

Me either. It's an oversight, really. Unless there is any objection I'll
change them toot sweet. What about the existing (as of 9.2) functions?

ISTM json_in, out, recv, send should also be immutable. array_to_json,
row_to_json et all can't be tho.

OK, although these have been like this since 9.2. I'm not sure why
json_out is immutable but json_in isn't.

Does changing these require a catalog version bump?

Yes.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

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