Pavel Stehule <pavel.stehule@gmail.com> writes: > here is rebased patch. > It contains both patches - row_to_array function and foreach array support.
While I don't have a problem with hstore_to_array, I don't think that row_to_array is a very good idea; it's basically encouraging people to throw away SQL datatypes altogether and imagine that everything is text.
This is complementation of ARRAY API - we have row_to_json, probably will have row_to_jsonb, row_to_hstore and "row_to_array" is relative logical. Casting to text is not fast, but on second hand - working with text arrays is fast.
I know so casting to text is a problem, but if you iterate over record's fields, then you have to find common shared type due sharing plans - and text arrays can be simple solution.
Now, with current possibilities I'll do full sql expression SELECT key, value FROM each(hstore(ROW)) or FOREACH ARRAY hstore_to_matrix(hstore(ROW))
row_to_array(ROW) can reduce a hstore overhead
any other solution based on PL/Perl or PL/Python are slower due PL engine start and due same transformation to some form of structured text.
They've already bought into that concept if they are using hstore or json, so smashing elements of those containers to text is not a problem. But that doesn't make this version a good thing.
(In any case, those who insist can get there through row_to_json, no?)
Also, could we please *not* mix up these two very independent features? "foreach array" as implemented here may or may not be a good thing, but it should get its own discussion.