Tom Lane wrote:
> If you did it that way then you'd not need that ugly kluge in
> RemoveType. What you'd need instead is some smarts (a kluge!?) in
> setting up the dependency. Currently that dependency is made in
> TypeCreate which doesn't know what sort of relation it's creating
> a type for. Probably the best answer is to pull that particular
> dependency out of TypeCreate, and make it (in the proper direction)
> in AddNewRelationType.
OK -- I'll take a look.
> Also, I'm not following the point of the separation between
> DefineCompositeType and DefineCompositeTypeRelation; nor do I see a need
> for a CommandCounterIncrement call in there.
Well the next thing I was going to work on after this was an implicitly
created composite type when creating a function. I thought maybe the
CommandCounterIncrement would be needed so that the type could be
created and then immediately used by the function. In any case, I'll
combine the two functions.
> You have missed a number of places where this new relkind ought to
> be special-cased the same way RELKIND_VIEW is --- for example
> CheckAttributeNames and AddNewAttributeTuples, since a composite type
> presumably shouldn't have system columns associated. I'd counsel
> looking at all references to RELKIND_VIEW to see which places also need
> to check for RELKIND_COMPOSITE_TYPE.
Yeah, after I fired off the post it occurred to me that I had neglected
to do that. I was just going through that exercise now.
Thanks for the (quick!) review. Round two will be probably sometime
tomorrow.
Joe
