Re: Re: Changing the default value of an inherited column

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Oliver Elphick" <olly(at)lfix(dot)co(dot)uk>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Changing the default value of an inherited column
Date: 2001-03-29 16:57:20
Message-ID: 22722.985885040@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Oliver Elphick" <olly(at)lfix(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-03-29 17:02:32 Re: Re: [PORTS] pgmonitor and Solaris
Previous Message Peter Eisentraut 2001-03-29 16:53:15 Re: Re: Changing the default value of an inherited column