On Fri, Nov 30, 2012 at 8:38 AM, Andrew Dunstan <andrew@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
