Re: Implementing standard SQL's DOMAIN constraint - Mailing list pgsql-general

From David G. Johnston
Subject Re: Implementing standard SQL's DOMAIN constraint
Date
Msg-id CAKFQuwY01E+8jfTtEZFzS4iXX1CNac3mWkVg1bOuop4CUVLEWw@mail.gmail.com
Whole thread Raw
In response to Re: Implementing standard SQL's DOMAIN constraint  (Rich Shepard <rshepard@appl-ecosys.com>)
Responses Re: Implementing standard SQL's DOMAIN constraint [RESOLVED]  (Rich Shepard <rshepard@appl-ecosys.com>)
List pgsql-general
On Wednesday, January 2, 2019, Rich Shepard <rshepard@appl-ecosys.com> 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 state_code is immaterial; the domain that you created doesn’t get
used.  There is no magic linking just by virtue of using the same name.

Change char(2) to state_code if you wish to apply the domain on the column.

David,

  I think I'm now on your page. In the schema I change the column data type
to state_code, then I add the SQL code creating the domain at the top of the
.sql file. Yes?


You add the create domain command once before any objects that make use of it.  If you only have one .sql file then at the top of it works.

David J.

pgsql-general by date:

Previous
From: Rich Shepard
Date:
Subject: Re: Implementing standard SQL's DOMAIN constraint
Next
From: Mark
Date:
Subject: Re: Query planner / Analyse statistics bad estimate rows=1 withmaximum statistics 10000 on PostgreSQL 10.2