Re: proposal: row_to_array function - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: proposal: row_to_array function
Date
Msg-id CADxJZo3cOJbQ0GW+Vf2SHGqKGcRA6P6G21RXodsuEkRMU5H-Pw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: row_to_array function  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On Thu, 2 Apr 2015 at 05:00 Merlin Moncure <mmoncure@gmail.com> wrote:
On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
...
>
> (In any case, those who insist can get there through row_to_json, no?)

You have a point.  What does attached do that to_json does not do
besides completely discard type information?
 
FWIW, I think row_to_array is nice, and I would make use of it.  If you have a record, and you want to iterate over its fields in a generic way, at least IMO converting to a text array is an obvious thing to reach for, and it makes for very clearly intentioned code.  While it's true that you could go through JSON or hstore to achieve much the same thing, it is a bit of a circumlocution.

I get Tom's point that smashing to text should not be done frivolously, but there are circumstances when it's a reasonable move.  Is it possible that it might be used unwisely?  Yes, but then you could say that about pretty much everything.

Would it alleviate your concerns at all if the function was named row_to_text_array, to stress the fact that you are throwing away data types?

If the patch was invasive, I would probably not support it, but from what I can see it's a pretty cheap add.

Cheers,
BJ

pgsql-hackers by date:

Previous
From: Eric Ridge
Date:
Subject: Re: Weirdness using Executor Hooks
Next
From: Michael Paquier
Date:
Subject: Re: pg_rewind failure by file deletion in source server