2015-01-16 18:42 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 1/16/15 11:22 AM, Pavel Stehule wrote: > >> >> >> 2015-01-16 18:03 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com <mailto: >> jim.na...@bluetreble.com>>: >> >> On 1/16/15 3:45 AM, Pavel Stehule wrote: >> >> I am returning back to processing records in plpgsql. >> >> I am thinking so it can be simply processed with transformations >> to array. >> >> Now we have similar functions - hstore(row), row_to_json, ... but >> using of these functions can be a useless step. Any row variable can be >> transformed to 2D text array. >> >> >> How is it useless? Why wouldn't you just use JSON and be done with it? >> >> >> We can use a FOREACH IN ARRAY iteration in plpgsql (second variant is a >> implementation FOREACH for jsonb) >> >> so ROW->ARRAY is shorter than ROW->JSON->ARRAY or ROW->HSTORE->ARRAY >> > > I think the real problem here is that we're inventing a bunch of different > ways to do the same thing: iterate over a set. Instead of doing that, > should we add the idea of an iterator to the type system? That would make > sense for arrays, hstore, json and XML. >
what do you think? How this can be implemented? > > Do you have some use cases you can share? >> >> >> processing of NEW, OLD variables in triggers >> > > Note that last time I checked you couldn't do something like NEW.variable, > and I don't think you could use EXEC to do it either. So there's more > needed here than just converting a record to an array. > > There two possible transformations: >> >> row_to_array --> [[key1, value1],[key2, value2], ...] >> row_to_row_array --> [(key1, value1), (key2, value2), ... ] >> >> >> If we're going to go that route, I think it makes more sense to >> create an actual key/value type (ie: http://pgxn.org/dist/pair/doc/ >> __pair.html <http://pgxn.org/dist/pair/doc/pair.html>) and return an >> array of that. >> >> >> ok >> >> -- >> Jim Nasby, Data Architect, Blue Treble Consulting >> Data in Trouble? Get it in Treble! http://BlueTreble.com >> >> >> > > -- > Jim Nasby, Data Architect, Blue Treble Consulting > Data in Trouble? Get it in Treble! http://BlueTreble.com >