On Tue, Mar 20, 2012 at 12:16 PM, Robert Haas <robertmhaas@xxxxxxxxx> wrote: > I think Tom's correct about what the right behavior would be if > composite types supported defaults, but they don't, never have, and > maybe never will. I had a previous argument about this with Tom, and > lost, though I am not sure that anyone other than Tom thinks that the > current behavior is for the best. But see commits > a06e41deebdf74b8b5109329dc75b2e9d9057962 and > a40b1e0bf32b1da46c1baa9bc7da87f207cd37d8. I'll go further than that -- given the current infrastructure I'd say that composite type defaults are not very well defined or useful besides not being implemented. The way things work now: create type foo as(a int, b int); create table bar(f foo default row(1,2)); works perfectly ok. how would you proxy the default from one of those two columns? does it make sense to do so? defaults are applied to table columns, not to types (you could argue that domains violate that rule but IMO it's not the same thing). type constraints are another matter. this would be useful and valuable but may end up being impossible to add for a lot of reasons such as backwards compatibility and dealing with the standard's lack (implemented nowhere in postgres except for the very special case of IS NULL) of distinguishing between the type itself being null and it's fields being null (making type constraints smack into plpgsql variable declarations). merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
