On Wed, Jan 26, 2011 at 3:48 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
