Re: proposal: row_to_array function

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: proposal: row_to_array function
Дата
Msg-id CAHyXU0xJHPJ2SWx=P28+vOsbs3+J=gGjU7gzQC0c2efqoAEP3A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: row_to_array function  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: row_to_array function  (Brendan Jurd <direvus@gmail.com>)
Re: proposal: row_to_array function  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
> 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?)

You have a point.  What does attached do that to_json does not do
besides completely discard type information?  Our json api is pretty
rich and getting richer.  For better or ill, we dumped all json
support into the already stupendously bloated public namespace and so
it's always available.

merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Tables cannot have INSTEAD OF triggers
Следующее
От: David Steele
Дата:
Сообщение: Re: Auditing extension for PostgreSQL (Take 2)