Ok. Updated patch attached.
- domain.patch -> source patch against pgsql in cvs
- drop_domain.sgml and create_domain.sgml -> New doc/src/sgml/ref docs
- dominfo.txt -> basic domain related queries I used for testing
Enables domains of array elements -> CREATE DOMAIN dom int4;
Uses a typbasetype column to describe the origin of the domain.
Copies data to attnotnull rather than processing in execMain().
Some documentation differences from earlier.
If this is approved, I'll start working on pg_dump, and a \dD <domain>
option in psql, and regression tests. I don't really feel like doing
those until the system table structure settles for pg_type.
CHECKS when added, will also be copied to to the table attributes. FK
Constraints (if I ever figure out how) will be done similarly. Both
will lbe handled by MergeDomainAttributes() which is called shortly
Any other recommendations?
This message represents the official view of the voices in my head
----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Rod Taylor" <rbt(at)zort(dot)ca>
Sent: Sunday, February 24, 2002 8:11 PM
Subject: Re: [PATCHES] Basic DOMAIN Support
> "Rod Taylor" <rbt(at)zort(dot)ca> writes:
> > I intend to add other parts of domain support later on (no reason
> > 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
> typelem to link domains to base types. All the array code is going
> 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
> separate column that links a domain to its base type. This'd also
> you from having to add another meaning to typtype (since a domain
> be recognized by nonzero typbasetype). That should reduce the
> likelihood of breaking existing code, and perhaps make life simpler
> 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
> 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
> 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
> 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
> nasty performance hit, especially seeing that people will pay it
> they ever heard of domains or not. And it seems quite unnecessary;
> you copy the domain's notnull bit into the pg_attribute row, then
> 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
> hardly any people using the feature, so this is not a serious
> but if any change has occurred it should be documented.
> Overall, an impressive first cut!
> regards, tom lane
Description: text/plain (2.7 KB)
Description: application/octet-stream (106.9 KB)
In response to
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2002-02-26 04:11:59|
|Subject: Re: Fix issuing of multiple command completions per command|
|Previous:||From: Tom Lane||Date: 2002-02-26 02:47:05|
|Subject: Re: Fix issuing of multiple command completions per command |