Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?

2013-04-15 Thread Andrew Dunstan


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?

2013-04-15 Thread hubert depesz lubaczewski
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?

2013-04-15 Thread Tom Lane
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?

2013-04-15 Thread Andres Freund
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?

2013-04-15 Thread Andrew Dunstan


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?

2013-04-15 Thread anara...@anarazel.de


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?

2013-04-15 Thread Bruce Momjian
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