Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 26, 2011 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I will agree that a language lawyer could argue that a table rowtype
>> doesn't have to act like a separately-declared composite type, but
>> that surely doesn't meet the POLA.
> 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.
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.
What I *don't* want to do is introduce another not-per-spec behavior
that we will have to make such hard choices about when the time comes,
when we aren't getting any meaningful functionality increment out of
allowing the not-per-spec behavior. And that's exactly the situation
with this ALTER case.
regards, tom lane
