Re: I/O support for composite types

> > regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4)));
>
> BTW, I forgot to mention that the keyword ROW is optional as long as
> you've got at least two items in the row expression, so the above can
> be simplified to
>
> regression=# insert into bar values (((1.1, 2.2), (3.3,4.4)));
> INSERT 155011 1
>
> Some other examples:
>
> regression=# select (1,2)::complex;
> ERROR: output of composite types not implemented yet
> regression=# select cast ((1,2) as complex);
> ERROR: output of composite types not implemented yet
>
> Looking at these, it does seem like it would be natural to get back
>
> complex
> ---------
> (1,2)
>
> so I'll now agree with you that the I/O syntax should use parens not
> braces as the outer delimiters.

Following this path, perhaps the array i/o syntax should be changed to use []s
and the keyword ARRAY should likewise be optional in the array constructor.

That would let people do things like "insert into bar values ([(1,2),(2,3)])"
to insert a list of point/complex data structures. and get back
'[(1,2),(2,3)]' in their dumps.

Personally I would have been more inclined to use braces for structs in both
places. And either parens or brackets for arrays. But eh. This whole thing is
just too cool to worry about the choice of delimiters.

--
greg