"Oliver Elphick" <olly@lfix.co.uk> writes:
>>>> Although the liberty to do anything you want seems appealing at first, I
>>>> would think that allowing this is not correct from an OO point of view.
> I don't agree; this is equivalent to redefinition of a feature (=method) in
> a descendant class, which is perfectly acceptable so long as the feature's
> signature (equivalent to column type) remains unchanged.
Well, that does bring up the question of exactly what is signature and
exactly what is implementation. Clearly we cannot allow the column type
to be redefined. But what about typmod? Is it OK to replace char(32)
with char(64)? How about vice versa? How about replacing numeric(9,0)
with numeric(7,2)?
The pre-7.0 code only checked that the type ID is the same, but I wonder
whether it wouldn't be a good idea to demand typmod the same as well.
For the existing types that use typmod I don't think this is absolutely
necessary (ie, I don't think the system might crash if typmods are
inconsistent in inherited tables) ... but I'm not comfortable about it
either.
regards, tom lane
