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

From Merlin Moncure
Subject Re: proposal: row_to_array function
Date
Msg-id CAHyXU0xJHPJ2SWx=P28+vOsbs3+J=gGjU7gzQC0c2efqoAEP3A@mail.gmail.com
Whole thread Raw
In response to Re: proposal: row_to_array function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: row_to_array function
Re: proposal: row_to_array function
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Tables cannot have INSTEAD OF triggers
Next
From: David Steele
Date:
Subject: Re: Auditing extension for PostgreSQL (Take 2)