By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,852 Members | 2,198 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,852 IT Pros & Developers. It's quick & easy.

DOMAIN usability

P: n/a

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.


Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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 pe*****@gmx.net
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #2

P: n/a
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.
Nov 12 '05 #3

P: n/a
On Fri, 14 Nov 2003 23:43:26 +0530
Rajesh Kumar Mallah <ma****@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 <je**@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.