On Wed, Jan 26, 2011 at 3:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, actually, what I thought was that the rowtype *should* act
>> exactly like a separately-declared composite rowtype. Which is to
>> say, it shouldn't have a default, because a separately-declared
>> composite rowtype *can't have a default*. If that's not the consensus
>> position, so be it, but it made sense to me.
>
> The fact that a separately-declared composite type can't have defaults
> is an implementation restriction. It is a feature required by SQL spec,
> so we ought to plan on doing it someday, IMO.
OK. Well, I think we need to document that somewhere, then, at least
in a comment; maybe in the documentation.
> It's conceivable that once we have that implemented, we will decide that
> table rowtypes should act differently from separately-declared composite
> types to the extent of not honoring defaults inherited from their table.
> That would be a terrible violation of POLA in my opinion, but we might
> have to do it for backwards compatibility's sake.
No, I wouldn't support that at all. I was simply assuming that there
was no intention for composite types to ever support defaults or
constraints, and like I say, we don't seem to worry about it anywhere
else (INSERT, SET NOT NULL, etc). I maintain it's pretty inconsistent
to do it only in this case, regardless of whether it's technically a
standards-compliance regression. The patch may make us less
consistent with the SQL spec, and it sounds like there are a couple
other votes for not doing it on that basis, but it makes us more
consistent with ourselves. If we ever support defaults and
constraints on composite types generally, then the behavior you're
imagining would seems like it would be the right thing to do.
Considering the number of OTHER places we'd have to break backward
compatibility, one more wouldn't bother me any, but apparently that's
just me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company