Re: I/O support for composite types

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: I/O support for composite types
Дата
Msg-id 87zn7buav8.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: I/O support for composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: I/O support for composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: thread safety tests
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Why hash indexes suck