Re: I/O support for composite types - Mailing list pgsql-hackers

From Greg Stark
Subject Re: I/O support for composite types
Date
Msg-id 87zn7buav8.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: I/O support for composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: I/O support for composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: thread safety tests
Next
From: Bruce Momjian
Date:
Subject: Re: Why hash indexes suck