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
think that a domain is an array, and proceed to do horribly wrong
things. User applications may think the same thing, so even if you
wanted to change every backend routine that looks at typelem, it
wouldn't be enough. I think the only safe way to proceed is to add a
separate column that links a domain to its base type. This'd also save
you from having to add another meaning to typtype (since a domain could
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?).

Come to think of it, even without freestanding composite types it'd be
possible to try to define a domain as a subtype of a composite type,
and to use same as (eg) a function argument or result type. I doubt
you are anywhere near making that behave reasonably, though. Might be
best to disallow it for now.

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.

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?

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.

Overall, an impressive first cut!

regards, tom lane