2015-03-29 20:27 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@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. > ok, I'll send two patches. > > regards, tom lane >
