On 4/28/15 1:31 PM, Andrew Dunstan wrote:
>
> 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.
Thanks, those are helpful. BTW, I think this is a memory leak in
populate_record_worker():
my_extra = (RecordIOData *) fcinfo->flinfo->fn_extra;if (my_extra == NULL || my_extra->ncolumns != ncolumns){
fcinfo->flinfo->fn_extra= MemoryContextAlloc(fcinfo->flinfo->fn_mcxt,
The part that I'm still concerned about in plpgsql is how to handle the
case of having a record that we should be able to associate with a
specific composite type (such as a table type). That's not currently
working in my patch, but I'm not sure why. Maybe I need to test for that
and in that case set the variable up as a PLPGSQL_TTYPE_ROW instead of
PLPGSQL_TTYPE_REC?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com