On Tue, Oct 11, 2011 at 8:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2011/10/11 Merlin Moncure <mmoncure@gmail.com>:
>> On Tue, Oct 11, 2011 at 3:40 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>> Hello
>>>
>>> A current limits of dynamic work with row types in PL/pgSQL can be
>>> decreased with a possible casts between rows and arrays. Now we have a
>>> lot of tools for arrays, and these tools should be used for rows too.
>>>
>>> postgres=# \d mypoint
>>> Composite type "public.mypoint"
>>> Column │ Type │ Modifiers
>>> ────────┼─────────┼───────────
>>> a │ integer │
>>> b │ integer │
>>>
>>> postgres=# select cast(rmypoint '(10,20) as int[]);
>>> array
>>> ────────────
>>> {10,20}
>>> (1 row)
>>>
>>> postgres=# select cast(ARRAY[10,20] AS mypoint);
>>> mypoint
>>> ─────────
>>> (10,20)
>>> (1 row)
>>>
>>> What do you think about this idea?
>>
>> Not sure what it buys you over the syntax we already have:
>>
>> select row(foo[1], bar[2]);
>> select array[(bar).a, (bar).b];
>
> You can do it manually for known combinations of rowtype and
> arraytype. But proposed casts do it generally - what has sense mainly
> for plpgsql functions or some sql functions.
>
>>
>> Also, in my coding of composite types, homogeneously typed rows don't
>> really come up that often...
>
> you can use everywhere text type.
>
> When I wrote
http://stackoverflow.com/questions/7711432/how-to-set-value-of-composite-variable-field-using-dynamic-sql/7722575#7722575
> then I had to do lot of string operations. Proposed casts
> significantly do this simply - and it is enought general for general
> usage.
How does your approach compare to hstore? hstore to me is just
enhanced generic container type which supports the operations you are
trying to do. It can be trivially (as of 9.0) moved in an out of both
arrays and record types:
postgres=# create type foo_t as (a int, b text, c float);
CREATE TYPE
postgres=# select row(1, 'abc', 1.0)::foo_t #= '"b"=>"def"';?column?
-----------(1,def,1)
(1 row)
merlin