Re: Implementing standard SQL's DOMAIN constraint [RESOLVED]

2019-01-02 Thread Rich Shepard
On Wed, 2 Jan 2019, Ron wrote: Note that a CHECK constraint with 50 items is a *Very Bad Idea*, since changing such a constraint is very painful. Use a FK constraint instead. Ron, It's even longer with Canadian provinces included. I gratefully accept your advice and will use a table and for

Re: Implementing standard SQL's DOMAIN constraint [RESOLVED]

2019-01-02 Thread Ron
On 1/2/19 12:05 PM, Rich Shepard wrote: On Wed, 2 Jan 2019, David G. Johnston wrote: You add the create domain command once before any objects that make use of it. David,   This is the answer I sought: postgres supports the create domain command. I did not see this in your first response.

Re: Implementing standard SQL's DOMAIN constraint [RESOLVED]

2019-01-02 Thread Rich Shepard
On Wed, 2 Jan 2019, David G. Johnston wrote: You add the create domain command once before any objects that make use of it. David, This is the answer I sought: postgres supports the create domain command. I did not see this in your first response. Thanks very much, Rich

Re: Implementing standard SQL's DOMAIN constraint

2019-01-02 Thread David G. Johnston
On Wednesday, January 2, 2019, Rich Shepard wrote: > On Wed, 2 Jan 2019, David G. Johnston wrote: > > I'm not following you. I have two tables each with a column, >>> state_code char(2) NOT NULL. >>> >> > That is a char(2) column for which ‘??’ is a valid value. The fact that it >> is named st

Re: Implementing standard SQL's DOMAIN constraint

2019-01-02 Thread Rich Shepard
On Wed, 2 Jan 2019, David G. Johnston wrote: I'm not following you. I have two tables each with a column, state_code char(2) NOT NULL. That is a char(2) column for which ‘??’ is a valid value. The fact that it is named state_code is immaterial; the domain that you created doesn’t get used.

Re: Implementing standard SQL's DOMAIN constraint

2019-01-02 Thread David G. Johnston
On Wednesday, January 2, 2019, Rich Shepard wrote: > On Wed, 2 Jan 2019, David G. Johnston wrote: > > There is no magic name logic involved. A domain is just a type with >> inherent constraints that are user definable. You make use of it like any >> other type. >> >> Create table tbl ( >> column_

Re: Implementing standard SQL's DOMAIN constraint

2019-01-02 Thread Rich Shepard
On Wed, 2 Jan 2019, David G. Johnston wrote: There is no magic name logic involved. A domain is just a type with inherent constraints that are user definable. You make use of it like any other type. Create table tbl ( column_name state_code not null ) Values stored in column_name are now of ty

Re: Implementing standard SQL's DOMAIN constraint

2019-01-02 Thread David G. Johnston
On Wednesday, January 2, 2019, Rich Shepard wrote: > > CREATE DOMAIN state_code AS char(2) > DEFAULT '??' > CONSTRAINT valid_state_code > CHECK (value IN ('AL', 'AK', 'AZ', ...)); > > This applies to all tables each having a column named state_code. > There is no magic name logic involved. A do

Implementing standard SQL's DOMAIN constraint

2019-01-02 Thread Rich Shepard
Happy New Year all, My readings taught me that standard SQL has a domain constraint that checks for the same valid characters in a column common to multiple tables. Example: CREATE DOMAIN state_code AS char(2) DEFAULT '??' CONSTRAINT valid_state_code CHECK (value IN ('AL', 'AK', 'AZ', ...)); Th