On Mon, 2003-05-12 at 10:59, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> > Quick patch to add the subject. Restructures all inheritance to consist
> > of a few flags to indicate which structures we want to inherit
>
> I think overloading the inheritance mechanism to serve this purpose is a
> bad idea. It complicates and confuses a significant amount of code
> that's already pretty confusing (no, I don't believe you found it all).
> It'd be better to have a localized bit of code that processes LIKE by
> generating a ColumnDef schema list.
That can be done without much of an issue. Much of the code in
MergeAttributes will be duplicated in this new routine.
I'll conduct the transform of LIKE to ColumnDef list within the
transformCreateStmt where the rest of the transformations take place.
> > Yes, I wish to add an option to allow check
> > constraints to be carried over despite the below note from Sect. 11.3:
>
> > NOTE 234 <column constraint>s, except for NOT NULL, are not included
> > in NCi; <column constraint definition>s are effectively transformed to
> > <table constraint definition>s and are thereby also excluded.
>
> Why is it a good idea to ignore the express requirement of the spec?
> (I'm not saying it's not a good idea --- that note seems a little odd
> to me too --- but presumably the spec writers had some reasons for
> doing it that way. I'd like some justification for not doing it their
> way.)
If you consider LIKE is allowed to inherit an IDENTIFIER, which is a
sequence based column with the intent that it will be a primary key,
then allowing inheritance of CONSTRAINTS (via an optional flag INCLUDING
CONSTRAINTS -- default is per spec) only makes sense.
UNDER (IHERITS) appears to allow constraints to be inherited.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc