Re: [HACKERS] proposal: row_to_array function

On Tue, Jun 23, 2015 at 3:45 PM, Jim Nasby wrote: > On 6/23/15 3:22 PM, Merlin Moncure wrote: >> >> I would rephrase that to: "do X to all fields of an object". >> Array handling is pretty good now (minus arrays of arrays, but arrays > > > Except that still won't make it easy to do something to ea

Re: [HACKERS] proposal: row_to_array function

On 6/23/15 3:40 PM, Pavel Stehule wrote: BTW, I think this relates to the desire to be able to do more OO-ish things in the database. Like "do X to all elements in this array". And to have actual classes, private members, real arrays of arrays. It seems like there's a bigger need

Re: [HACKERS] proposal: row_to_array function

On 6/23/15 3:22 PM, Merlin Moncure wrote: I would rephrase that to: "do X to all fields of an object". Array handling is pretty good now (minus arrays of arrays, but arrays Except that still won't make it easy to do something to each element of an array in SQL, which I think would be nice to h

Re: [HACKERS] proposal: row_to_array function

2015-06-23 21:57 GMT+02:00 Jim Nasby : > On 6/23/15 9:45 AM, Pavel Stehule wrote: > >> >> 2015-06-23 1:56 GMT+02:00 Jim Nasby > >: >> >> >> On 6/22/15 2:46 AM, Pavel Stehule wrote: >> >> >> FOREACH key, val IN RECORD myrow >> LOOP >>

Re: [HACKERS] proposal: row_to_array function

On Tue, Jun 23, 2015 at 2:57 PM, Jim Nasby wrote: > On 6/23/15 9:45 AM, Pavel Stehule wrote: >> 1. parametrized record reference syntax - some like SELECT $1[$] >> 2. possibility to throw plan cache, if result has different type than is >> expected in cache. > > > Well, the other option is we allo

Re: [HACKERS] proposal: row_to_array function

On 6/23/15 9:45 AM, Pavel Stehule wrote: 2015-06-23 1:56 GMT+02:00 Jim Nasby mailto:jim.na...@bluetreble.com>>: On 6/22/15 2:46 AM, Pavel Stehule wrote: FOREACH key, val IN RECORD myrow LOOP IF pg_typeof(val) IN ('int4', 'double precision', 'numeric') T

Re: [HACKERS] proposal: row_to_array function

2015-06-23 1:56 GMT+02:00 Jim Nasby : > On 6/22/15 2:46 AM, Pavel Stehule wrote: > >> >> FOREACH key, val IN RECORD myrow >> LOOP >>IF pg_typeof(val) IN ('int4', 'double precision', 'numeric') THEN >> val := val + 1; -- these variables can be mutable >> -- or maybe in futore >> m

Re: [HACKERS] proposal: row_to_array function

On 6/22/15 2:46 AM, Pavel Stehule wrote: FOREACH key, val IN RECORD myrow LOOP IF pg_typeof(val) IN ('int4', 'double precision', 'numeric') THEN val := val + 1; -- these variables can be mutable -- or maybe in futore myrow[key] := val + 1; END IF; END LOOP; What is important

Re: [HACKERS] proposal: row_to_array function

Hi 2015-06-22 5:18 GMT+02:00 Craig Ringer : > On 2 April 2015 at 01:59, Merlin Moncure wrote: > > On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane wrote: > >> Pavel Stehule writes: > >>> here is rebased patch. > >>> It contains both patches - row_to_array function and foreach array > support. > >> >

Re: [HACKERS] proposal: row_to_array function

On 2 April 2015 at 01:59, Merlin Moncure wrote: > On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane wrote: >> Pavel Stehule 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

Re: [HACKERS] proposal: row_to_array function

On Thu, 2 Apr 2015 at 05:00 Merlin Moncure wrote: > On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane 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 im

Re: [HACKERS] proposal: row_to_array function

On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane wrote: > Pavel Stehule 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 basi

Re: [HACKERS] proposal: row_to_array function

2015-03-29 21:20 GMT+02:00 Pavel Stehule : > > > 2015-03-29 20:27 GMT+02:00 Tom Lane : > >> Pavel Stehule 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

Re: [HACKERS] proposal: row_to_array function

2015-03-29 20:27 GMT+02:00 Tom Lane : > Pavel Stehule 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 e

Re: [HACKERS] proposal: row_to_array function

Pavel Stehule 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 altoge

Re: [HACKERS] proposal: row_to_array function

Hi here is rebased patch. It contains both patches - row_to_array function and foreach array support. This design is in conformity with hstore functions. There can be good synergy. Regards Pavel 2015-03-28 23:53 GMT+01:00 Jeff Janes : > On Tue, Jan 27, 2015 at 10:58 AM, Pavel Stehule > wrot

Re: [HACKERS] proposal: row_to_array function

On Tue, Jan 27, 2015 at 10:58 AM, Pavel Stehule wrote: > Hi > > 2015-01-27 11:41 GMT+01:00 Pavel Stehule : > >> >> >> 2015-01-26 21:44 GMT+01:00 Jim Nasby : >> >>> On 1/25/15 4:23 AM, Pavel Stehule wrote: >>> I tested a concept iteration over array in format [key1, value1, key2, va

Re: [HACKERS] proposal: row_to_array function

2015-01-28 6:49 GMT+01:00 Pavel Stehule : > > Dne 28.1.2015 0:25 "Jim Nasby" napsal(a): > > > > On 1/27/15 12:58 PM, Pavel Stehule wrote: > >> > >> postgres=# select array(select > unnest('{{{1,2},{3,4}},{{5,6},{7,8}}}'::int[])); > >> array > >> --- > >>

Re: [HACKERS] proposal: row_to_array function

2015-01-28 0:16 GMT+01:00 Jim Nasby : > On 1/27/15 2:26 PM, Pavel Stehule wrote: > >> here is a initial version of row_to_array function - transform any row to >> array in format proposed by Andrew. >> > > Please start a new thread for this... does it depend on the key-value > patch? partially -

Re: [HACKERS] proposal: row_to_array function

Dne 28.1.2015 0:25 "Jim Nasby" napsal(a): > > On 1/27/15 12:58 PM, Pavel Stehule wrote: >> >> postgres=# select array(select unnest('{{{1,2},{3,4}},{{5,6},{7,8}}}'::int[])); >> array >> --- >> {1,2,3,4,5,6,7,8} >> (1 row) >> >> so it generate pai

Re: [HACKERS] proposal: row_to_array function

On 1/27/15 12:58 PM, Pavel Stehule wrote: postgres=# select array(select unnest('{{{1,2},{3,4}},{{5,6},{7,8}}}'::int[])); array --- {1,2,3,4,5,6,7,8} (1 row) so it generate pairs {1,2}{3,4},{5,6},{7,8} I fixed situation when array has not en

Re: [HACKERS] proposal: row_to_array function

On 1/27/15 2:26 PM, Pavel Stehule wrote: here is a initial version of row_to_array function - transform any row to array in format proposed by Andrew. Please start a new thread for this... does it depend on the key-value patch? -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Troub

Re: [HACKERS] proposal: row_to_array function

Example: postgres=# do $$ declare r record; declare k text; v text; begin for r in select * from foo loop foreach k,v in array row_to_array(r) loop raise notice 'k: %, v: %', k, v; end loop; end loop; end; $$; NOTICE: k: a, v: 2 NOTICE: k: b, v: NAZDAR NOTICE: k: c, v: 2015-01

Re: [HACKERS] proposal: row_to_array function

Hello here is a initial version of row_to_array function - transform any row to array in format proposed by Andrew. Regards Pavel 2015-01-27 19:58 GMT+01:00 Pavel Stehule : > Hi > > 2015-01-27 11:41 GMT+01:00 Pavel Stehule : > >> >> >> 2015-01-26 21:44 GMT+01:00 Jim Nasby : >> >>> On 1/25/15 4

Re: [HACKERS] proposal: row_to_array function

Hi 2015-01-27 11:41 GMT+01:00 Pavel Stehule : > > > 2015-01-26 21:44 GMT+01:00 Jim Nasby : > >> On 1/25/15 4:23 AM, Pavel Stehule wrote: >> >>> >>> I tested a concept iteration over array in format [key1, value1, key2, >>> value2, .. ] - what is nice, it works for [[key1,value1],[key2, value2], >

Re: [HACKERS] proposal: row_to_array function

2015-01-26 21:44 GMT+01:00 Jim Nasby : > On 1/25/15 4:23 AM, Pavel Stehule wrote: > >> >> I tested a concept iteration over array in format [key1, value1, key2, >> value2, .. ] - what is nice, it works for [[key1,value1],[key2, value2], >> ...] too >> >> It is only a few lines more to current code

Re: [HACKERS] proposal: row_to_array function

On 1/25/15 4:23 AM, Pavel Stehule wrote: I tested a concept iteration over array in format [key1, value1, key2, value2, .. ] - what is nice, it works for [[key1,value1],[key2, value2], ...] too It is only a few lines more to current code, and this change doesn't break a compatibility. Do you

Re: [HACKERS] proposal: row_to_array function

Hi I tested a concept iteration over array in format [key1, value1, key2, value2, .. ] - what is nice, it works for [[key1,value1],[key2, value2], ...] too It is only a few lines more to current code, and this change doesn't break a compatibility. Do you think, so this patch is acceptable? Idea

Re: [HACKERS] proposal: row_to_array function

2015-01-17 7:26 GMT+01:00 Pavel Stehule : > > 2015-01-16 22:35 GMT+01:00 Andrew Dunstan : > >> >> On 01/16/2015 12:22 PM, Pavel Stehule wrote: >> >>> >>> >>> There two possible transformations: >>> >>> row_to_array --> [[key1, value1],[key2, value2], ...] >>> row_to_row_arr

Re: [HACKERS] proposal: row_to_array function

2015-01-16 22:35 GMT+01:00 Andrew Dunstan : > > On 01/16/2015 12:22 PM, Pavel Stehule wrote: > >> >> >> There two possible transformations: >> >> row_to_array --> [[key1, value1],[key2, value2], ...] >> row_to_row_array --> [(key1, value1), (key2, value2), ... ] >> >> >>

Re: [HACKERS] proposal: row_to_array function

On 01/16/2015 12:22 PM, Pavel Stehule wrote: There two possible transformations: row_to_array --> [[key1, value1],[key2, value2], ...] row_to_row_array --> [(key1, value1), (key2, value2), ... ] If we're going to go that route, I think it makes more sense to

Re: [HACKERS] proposal: row_to_array function

2015-01-16 18:42 GMT+01:00 Jim Nasby : > On 1/16/15 11:22 AM, Pavel Stehule wrote: > >> >> >> 2015-01-16 18:03 GMT+01:00 Jim Nasby > jim.na...@bluetreble.com>>: >> >> On 1/16/15 3:45 AM, Pavel Stehule wrote: >> >> I am returning back to processing records in plpgsql. >> >> I am

Re: [HACKERS] proposal: row_to_array function

On 1/16/15 11:22 AM, Pavel Stehule wrote: 2015-01-16 18:03 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>: On 1/16/15 3:45 AM, Pavel Stehule wrote: I am returning back to processing records in plpgsql. I am thinking so it can be simply processed with transformation

Re: [HACKERS] proposal: row_to_array function

2015-01-16 18:03 GMT+01:00 Jim Nasby : > On 1/16/15 3:45 AM, Pavel Stehule wrote: > >> I am returning back to processing records in plpgsql. >> >> I am thinking so it can be simply processed with transformations to array. >> >> Now we have similar functions - hstore(row), row_to_json, ... but usin

Re: [HACKERS] proposal: row_to_array function

On 1/16/15 3:45 AM, Pavel Stehule wrote: I am returning back to processing records in plpgsql. I am thinking so it can be simply processed with transformations to array. Now we have similar functions - hstore(row), row_to_json, ... but using of these functions can be a useless step. Any row va

[HACKERS] proposal: row_to_array function

Hi I am returning back to processing records in plpgsql. I am thinking so it can be simply processed with transformations to array. Now we have similar functions - hstore(row), row_to_json, ... but using of these functions can be a useless step. Any row variable can be transformed to 2D text arr