On Fri, Nov 30, 2012 at 8:38 AM, Andrew Dunstan <and...@dunslane.net> wrote: > OK, so based on this discussion, I'm thinking of the following:
ok, this is looking awesome -- couple naming suggestions (see inline): > * keep the original functions and operators. json_keys is still > required for the case where the json is not flat. > * json_each(json) => setof (text, text) > errors if the json is not a flat object > * json_unnest(json) => setof json > errors if the json is not an array I wonder if usage of 'unnest' is appropriate: sql unnest() *completely* unwraps the array to a list of scalars where as json unnest() only peels of one level. If you agree with that (it's debatable), how about json_array_each()? > * json_unnest_each => setof (int, text, text) > errors if the array is not an array of flat objects I like this. Maybe json_object_each() if you agree with my analysis above. > * populate_record(record, json) => record > errors if the json isn't a flat object > * populate_recordset(record, json) => setof record > errors if the json is not an array of flat objects Two questions: 1) is it possible for these to work without a polymorphic object passed through as hstore does (null::foo)? select populate_record(anyelement, record, json) 2) in keeping with naming style of json api, how about json_to_record, json_to_recordset? Maybe though keeping similarity with hstore convention is more important. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
