Re: proposal: row_to_array function

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: row_to_array function
Date: 2015-04-01 17:59:34
Message-ID: CAHyXU0xJHPJ2SWx=P28+vOsbs3+J=gGjU7gzQC0c2efqoAEP3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2015-04-01 18:00:55 Re: Auditing extension for PostgreSQL (Take 2)
Previous Message Tom Lane 2015-04-01 17:56:10 Re: Tables cannot have INSTEAD OF triggers