On Tue, Mar 20, 2012 at 12:16 PM, Robert Haas <robertmhaas@gmail.com> 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
