[HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?
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. Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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
Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?
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
Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?
Andrew Dunstan and...@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
Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?
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
Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?
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
Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?
Andrew Dunstan and...@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
Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?
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 br...@momjian.ushttp://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
