On 04/28/2015 01:44 PM, Jim Nasby wrote:
> On 4/27/15 10:06 PM, Andrew Dunstan wrote:
>> My point remains that we really need methods of a) getting the field
>> names from generic records and b) using text values to access fields of
>> generic records, both as lvalues and rvalues. Without those this feature
>> will be of comparatively little value, IMNSHO. With them it will be much
>> more useful and powerful.
>
> Sure, and if I had some pointers on what was necessary there I'd take
> a look at it. But I'm not very familiar with plpgsql (let alone what
> we'd need to do this in SQL), so I'd just be fumbling around. As a
> reminder, one of the big issues there seems to be that while plSQL
> knows what the underlying type is, plpgsql has no idea, which
> seriously limits the use of passing it a record.
>
> In the meantime I've got a patch that definitely works for plSQL and
> allows you to handle a record and pass it on to other functions (such
> as json_from_record()). Since that's my original motivation for
> looking at this, I'd like that patch to be considered unless there's a
> big drawback to it that I'm missing. (For 9.6, of course.)
If you look at composite_to_json() it gives you almost all that you'd
need to construct an array of field names for an arbitrary record, and a
lot of what you'd need to extract a value for an arbitrary field.
populate_record_worker() has a good deal of what you'd need to set a
value of an arbitrary field. None of that means that there isn't a good
deal of work do do, but if you want pointers there are some.
cheers
andrew