Re: Basic DOMAIN Support

> "Rod Taylor" <rbt(at)zort(dot)ca> writes:
> > I intend to add other parts of domain support later on (no reason
to
> > hold up committing this though) but would appreciate some feedback
> > about what I've done.
>
> Still needs some work ...
>
> One serious problem is that I do not think you can get away with
reusing
> typelem to link domains to base types. All the array code is going
to
<-- snip-->
> be recognized by nonzero typbasetype). That should reduce the
> likelihood of breaking existing code, and perhaps make life simpler
when
> it comes time to allow freestanding composite types (why shouldn't a
> domain have a composite type as base?).

Will add pg_type.typbasetype, and can really easily allow domains of
composite types if this is wanted. I don't really understand
composite types, so I have no idea how this would work.

> Speaking of arrays --- have you thought about arrays of domain-type
> objects? I'm not sure whether any of the supported features matter
for
> array elements, but if they do it's not clear how to make it happen.

I wondered about this too, but I've been able to regress the system as
well as use it for other basic tasks. The main reason that a domain
isn't a base type is to prevent a domain of domains. The few books I
have that describe domains state that they shouldn't. Marking it with
a 'd' makes it quite obvious it's a domain and not intended for
grouping into subdomains.

One can make a domain of an array easily enough, then apply
constraints to each segment of it -- but hadn't considered an array of
domains. In the end they can both come out to the same thing. Check
constraints aren't currently available of course, but the below will
work the same.

-- Potentially allowed, but untested (likley broken, but maybe
not...).
create domain dom1 int2[2] check (VALUE[1] > 5 and VALUE[2] > 5);
create table tab1 (arr1 dom1);

or

-- Not allowed, and not easily arranged.
create domain dom2 int2 check (VALUE > 5);
create table tab2 (arr2 dom2[2]);

> Another objection is the changes you made in execMain.c. That extra
> syscache lookup for every field of every tuple is going to be a
rather
> nasty performance hit, especially seeing that people will pay it
whether
> they ever heard of domains or not. And it seems quite unnecessary;
if
> you copy the domain's notnull bit into the pg_attribute row, then
the
> existing coding will do fine, no?

Did that originally with a function called MergeDomainAttributes()
(since removed). The goal was to allow the user to change table
attributes without overriding the domain. The constraints are
'merged' on execution for every other constraint type (default is
wacky though), so don't see why NOT NULL should be special. This
could be done with a new column pg_attribute.attypnotnull and have the
type null / not null data copied there. Of course, ALTER DOMAIN is
going to get rather complex searching for all of those areas.

That said, I rarely see a table without atleast one NOT NULL
constraint (primary key usually) except for perhaps a log, so is it
really a big performance hit? I thought I saved a couple of cycles by
dropping the IF :)

> I think also that you may have created some subtle changes in the
> semantics of type default-value specifications; we'll need to think
> if any compatibility problems have been introduced. There are
doubtless
> hardly any people using the feature, so this is not a serious
objection,
> but if any change has occurred it should be documented.

Where would I put the docs for this? CREATE TYPE ref notes? or is the
history released at release adequate for this?