Re: Better support for whole-row operations and composite types - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Better support for whole-row operations and composite types
Date
Msg-id 87ad1zs1rm.fsf@stark.xeocode.com
Whole thread Raw
In response to Better support for whole-row operations and composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Better support for whole-row operations and composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Increasing security in a shared environment ...
Next
From: markw@osdl.org
Date:
Subject: Re: PostgreSQL block size vs. LVM2 stripe width