Re: Domain Support -- another round

I've committed a bunch of changes after code review of your DOMAIN
patch.  There were a number of minor bugs as well as some stylistic
things I didn't like.

Probably the largest change was that I concluded we had to revert the
handling of default values for base types to the old way: simple literal
stored as a string.  You can't meaningfully deal with an expression that
represents a value of a type you haven't defined yet --- since you
surely haven't defined any functions or operators that yield it, either.
Therefore the apparent flexibility is illusory.  Also, the code just
plain didn't work: after I fixed preptlist.c to do what it should be
doing, I was getting "can't coerce" failures in the create_type
regression test.  (For example, it didn't believe that an int4 literal
"42" was a valid default for the test's type int42, which is correct
given that the test doesn't define any conversion function...)  So all
in all I just don't see any way that can work.  I've set it up so that
you can have *either* an expression default (if typdefaultbin is not
null) *or* a simple literal default (if typdefaultbin is null but
typdefault isn't).  The former case will work for domains, the latter
for base types.

There are still some things that need to be worked on:

1. pg_dump.  We *cannot* release this feature in 7.3 if there's not
pg_dump support for it.

2. Arrays.  I don't much care for the fact that arrays of domain-type
values aren't supported.  The handling of domains that are themselves
arrays seems a tad odd as well: the array-ish nature of the domain is
exposed, which doesn't make a lot of sense to me.  Perhaps we'd be
better off to forbid array domains.

3. Domains on domains.  Why shouldn't I be able to make a domain that's
a further restriction of another domain?

4. CHECK constraints for domains (which after all is the real point,
no?)

            regards, tom lane