|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>|
|Cc:||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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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?)
Also, could we please *not* mix up these two very independent features?
"foreach array" as implemented here may or may not be a good thing, but
it should get its own discussion.
regards, tom lane
|Next Message||Fabien COELHO||2015-03-29 18:29:34||Re: getting rid of "thread fork emulation" in pgbench?|
|Previous Message||Fabien COELHO||2015-03-29 18:20:46||Re: extend pgbench expressions with functions|