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

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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