Обсуждение: 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 | sjson_out | ijson_recv
| sjson_send | sarray_to_json | sarray_to_json | srow_to_json
|srow_to_json | sjson_agg_transfn | ijson_agg_finalfn | ijson_agg |
ito_json | sjson_object_field | sjson_object_field_text | sjson_array_element |
sjson_array_element_text | sjson_extract_path | sjson_extract_path_op | sjson_extract_path_text |
sjson_extract_path_text_op| sjson_array_elements | sjson_array_length | sjson_object_keys |
sjson_each | sjson_each_text | sjson_populate_record | sjson_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/
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
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
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
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
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
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 somepoint. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone.
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. +