On Tue, Jan 12, 2010 at 9:00 AM, Andrew Dunstan <and...@dunslane.net> wrote: > What is the point of this discussion? We're not going to remove the facility > for composite types, regardless of whether or not some people regard them as > unnecessary. And "a name that better suits the task" is not to be sneered at > anyway.
nobody is arguing to remove the create type syntax. I suppose in hindsight more thought might have been given to the overlap w/create table. Also you have to admit that having both 'create type' and 'create type as' which do completely different things is pretty awkward. in addition, we have 'create table' which gives us three different methods of creating types, each with their own nuance and advantages. please understand, I'm not griping: the postgresql type system is wonderful...there's nothing else quite like it out there. The questions I am posing are this: *) should 'create type as' get an 'alter'? ( I think most would think so) *) if so, how do you distinguish between the composite and non composite version? How would this command look? *) should we be able to define check constraints on composite types (presumably, enforced on a cast)? *) should 'create type as' should be walled off with 'create table' handling most cases of type creation? (previously would have said yes, but with typed table enhancement, probably not) merlin merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers