Re: Better support for whole-row operations and composite types

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Better support for whole-row operations and composite types
Дата
Msg-id 87ad1zs1rm.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Better support for whole-row operations and composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Better support for whole-row operations and composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> We have a number of issues revolving around the fact that composite types
> (row types) aren't first-class objects.  I think it's past time to fix
> that.  
...
> Only named composite types, not RECORD, will be allowed to be used as
> table column types.  

If I understand what you're talking about, you would be allowed to CREATE TYPE
a composite type, like say, "address" and then use that as a datatype all over
your database? And then if you find "address" needs a new field you can add it
to the type and automatically have it added all over your database to any
table column using that type?

Speaking as a user, that would be **very** nice. I've often found myself
wishing for just such a feature. It would simplify data model maintenance a
whole heck of a lot.

How will client programs see the data if i do a "select *"? In my ideal world
it would be shipped over in a binary representation that a driver would
translate to a perl hash / php array / whatever. But maybe it would be simpler
to just ship them over the subcolumns with names like "shipping.line_1" and
"shipping.country".



-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: Increasing security in a shared environment ...
Следующее
От: markw@osdl.org
Дата:
Сообщение: Re: PostgreSQL block size vs. LVM2 stripe width