Skip site navigation (1) Skip section navigation (2)

Re: Domain Support -- another round

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>,<pgsql-patches(at)postgresql(dot)org>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Domain Support -- another round
Date: 2002-03-21 15:03:20
Message-ID: 033201c1d0e9$8bbad840$5302000a@jester (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
> 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.

I intend to try to do this next week.

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

The reason I didn't make array types for domains is that I have
absolutly no idea how to manage the below case once point 4 is

create domain dom as int4 check (VALUE > 5);
create table tab (col1 dom[2][3]);

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

Not entirely sure, except the book I had (SQL99 Complete, Really)
specifically forbids it.

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

Yes, I'm slow and only capable of one step at a time.  Foreign key
constraints are the other real point.

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2002-03-21 15:26:49
Subject: Re: Linux/mips compile should not use -mips2
Previous:From: Thomas LockhartDate: 2002-03-21 13:51:50
Subject: Re: Domains and type coercion

pgsql-patches by date

Next:From: Fernando NasserDate: 2002-03-21 15:32:19
Subject: Re: Domain Support -- another round
Previous:From: Bruce MomjianDate: 2002-03-21 14:43:20
Subject: Re: pg_dump and transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group