Re: stand-alone composite types patch (was [HACKERS] Proposal:

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.

Fixed.

> 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.

Fixed.


> 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.

Yup, I had missed lots of things, not the least of which was pg_dump. 
New patch attached includes pg_dump, psql (\dT), docs, and regression 
support.

There is also a small adjustment to the expected output file for 
select-having. I was getting a regression failure based on ordering of 
the results, so I added ORDER BY clauses.

Passes all regression tests. If no more objections, please apply.

Thanks,

Joe