Re: proposal: row_to_array function

Поиск
Список
Период
Сортировка
От Brendan Jurd
Тема Re: proposal: row_to_array function
Дата
Msg-id CADxJZo3cOJbQ0GW+Vf2SHGqKGcRA6P6G21RXodsuEkRMU5H-Pw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: row_to_array function  (Merlin Moncure <mmoncure@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Eric Ridge
Дата:
Сообщение: Re: Weirdness using Executor Hooks
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_rewind failure by file deletion in source server