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.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to