Обсуждение: DOMAIN usability

Hi  ,

I think one of the usage patterns of  DOMAINS is
to have size specifications and validity constraints
at one place for easy administration of Database.

Eg, instead of declaring email to be varchar(30) in
10s of tables  and putting a CHECK constraint for
presence of  '@'  we could declare

CREATE DOMAIN email_type varchar (30) CHECK ( value ~* '@') ;

And users could use "email_type" in our CREATE TABLEs .


There are two main issues (problems)

1. Suppose varchar(30) turns out to be too small oneday
    and we want to increase it to varchar(100)  , what do i do ?
    a)   Create a new domain ,
    b)  Apply all  the constraints  on new domain
    c)  Create new column in each of the tables and copy the old column
    d)  drop the old domain cascaded.

    any other more elegent method ?


2. Its difficult to see all the constraint defs on a domain .
    information_schema.domain_constriants does not have the
   definations just the names are present.

Regards
Mallah.

Rajesh Kumar Mallah writes:

> *1.* Suppose varchar(30) turns out to be too small oneday
>     and we want to increase it to varchar(100)  , what do i do ?

This is no different from the problem of changing a column type in place.
It's still being worked on.

> *2.* Its difficult to see all the constraint defs on a domain .
>     information_schema.domain_constriants does not have the
>    definations just the names are present.

You need to join domain_constraints and check_constraints.

--
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut wrote:

Rajesh Kumar Mallah writes:
 

*1.* Suppose varchar(30) turns out to be too small oneday   and we want to increase it to varchar(100)  , what do i do ?   

This is no different from the problem of changing a column type in place.
It's still being worked on.

Yes i realize so. But what could be in principle wrong to allow increasing
storage size only  eg varchar(30) to varchar(100)  not integer to varchar(100)
etc. I remeber there was already a long thread of discussion on it.

BTW: Searching on archives.postgresql.org takes ages is it using FTS?

*2.* Its difficult to see all the constraint defs on a domain .   information_schema.domain_constriants does not have the  definations just the names are present.   

You need to join domain_constraints and check_constraints.

thanks.

Regds
Mallah.

-- 

Rajesh Kumar Mallah,
Infocom Network Limited, New Delhi
phone: +91(11)6152172 (221) (L) ,9811255597 (M)

Visit http://www.trade-india.com ,
India's Leading B2B eMarketplace.

On Fri, 14 Nov 2003 23:43:26 +0530
Rajesh Kumar Mallah <mallah@trade-india.com> wrote:

>
> BTW: Searching on archives.postgresql.org takes ages is it using FTS?
>

Groups.google.com has indexes of the mailing lists so you can use that
to search. I do because archives is unusably slow.

you know. we should do something about that :)


--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/