On 01/31/2014 02:48 PM, Merlin Moncure wrote:
Actually, there is a workaround to the limitations of hstore(record):
yeah I'm ok with hstore() function as it is. That also eliminates
backwards compatibility concerns so things worked out. The only 'must
fix' 9.4 facing issue I see on the table is to make sure jsonb
populate function is forward compatible with future expectations of
behavior which to me means zeroing in on the necessity of the as_text
argument (but if you can expand coverage without jeopardizing 9.4
inclusion than great...).
This isn't terribly clear. Currently, if jsonb_populate_record{set}
encounters a nested array or object when populating the record it errors
out, regardless of the type of the field, unless as_text is set (it
defaults to off). In the latter case it tries to use the array or
object's json text representation as the value to populate the field
(realistically, this only works for text, json and jsonb fields). This
is exactly the current behaviour of json_populate_record{set}. The
enhancement would be to alter the behaviour when as_text is NOT set. In
this case, we would try recursively to populate an array or composite
field with the corresponding jsonb. i.e we would be removing some
current error conditions and returning a result. But we would not be
returning a different result in any case where we now return a result. I
think that's future-proof enough.
Frankly, I think the behaviour of hstore(record) with nested composites
and arrays is sufficiently counter-intuitive, to put it mildly, that we
should at least document the workaround from my previous email.
For my part I'm going to continue functionally testing the rest of the
API (so far, a cursory look hasn't turned up anything else). I'm also
signing up for some documentation refinements which will be done after
you nail down these little bits but before the end of the 'fest.
IMNSHO, formal code review needs to begin ASAP (salahaldin is the
reviewer per the fest wiki)
Yes, or anyone else who wants to join in. I'd very much welcome a
substantial code review - I have been staring at this far too long on my
own.
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
