In PostgreSQL 9.5 I'm wanting to create a table with three columns. I'd basically have something like
create table Foo (
account varchar not null,
team_id integer references team (ident) on delete cascade,
league_id integer references league (ident) on delete cascade
)
The fun part now is that I want them to specify EITHER team_id OR league_id, but not both. The combination of account plus one of the other two columns is then the UNIQUE constraint.
Is that possible to do?
To make sure only one of the columns is supplied, use a check constraint:
alter table foo add
constraint check_team check (not (team_id is not null and league_id is not null));
The above will however not prevent providing a NULL value for both columns. If you want to make sure that exactly one of them is provided you can use:
alter table foo add
constraint check_team check ( (team_id is not null or league_id is not null)
and not (team_id is not null and league_id is not null));
Edit: as Abelisto pointed out, the check constraint can be simplified to
alter table foo add
constraint check_team check ((team_id is null) <> (league_id is null));
I'm not sure about the unique constraint you want to establish. If e.g. the following two rows should be prevented ('x', 1, null), ('x', null, 1) then you can use a unique index like this:
create unique index on foo (account, coalesce(team_id, league_id));
That would only work properly if you enforce the rule that at least one of those columns must be not null.
If however you want to allow the same team in different columns, but want to prevent to have he same team_id or league_id twice for an account (allowing the above example) then I think you need to unique indexes:
create unique index on foo (account, team_id) where team_id is not null;
create unique index on foo (account, league_id) where league_id is not null;
Related
I'm trying to add a NOT NULL constraint in PostgreSQL, but can't find the right syntax.
Here is, essentially, what I'm trying to do:
ALTER TABLE olimpic.tb_athlete
ADD CONSTRAINT soloESP CHECK(country = 'ESP' AND substitute_id IS NOT NULL)
and the table I'm trying to modify:
CREATE TABLE olimpic.tb_athlete
(
athlete_id CHAR(7) PRIMARY KEY,
name VARCHAR(50) NOT NULL,
country CHAR(3) NOT NULL,
substitute_id CHAR(7),
FOREIGN KEY (substitute_id) REFERENCES olimpic.tb_athlete(athlete_id)
);
I have already deleted or set default values to the column country where the value is 'ESP', with this code being an example:
DELETE FROM olimpic.tb_athlete
where substitute_id is NULL and country = 'ESP';
but I'm still getting the following error:
ERROR: ERROR: check constraint 'soloESP' on table tb_athlete is violated by some row
SQL state: 23514
Any help you could give me as to how to proceed would be greatly appreciated.
Do you realize that the constraint you're trying to add does not allow any rows with the country field other than 'ESP'? You say you want two conditions simultaneously (because you use the AND operator): each row must have country = 'ESP' AND non-null substitute_id
I believe what you wanted is
ALTER TABLE olimpic.tb_athlete
ADD CONSTRAINT soloESP CHECK(country != 'ESP' OR substitute_id IS NOT NULL);
This constraint will ensure that if country = 'ESP' then substitute_id must be non-null. For other countries both null and non-null values of substitute_id are valid.
But the above is only a guess because you provided neither your database's schema, nor meanings of the fields, nor the error text in English, nor the data stored in your database so that we could analyze what is really happening in your case. Please, consider editing the question to add the above
I'm guessing the answer is no, but... is it possible to enforce uniqueness on only part of a composite primary key?
create table foo (
id integer,
yesno boolean,
extra text,
primary key (id, yesno, extra)
)
The idea here is that I want id + yesno to be unique for this particular table, but I want to include extra in the index so I can take advantage of Postgres index-only scans.
Yes, I could create a second, unique index on id + yesno, but that would be wasteful.
You can use the INCLUDE option to add extra columns in the index that are not actually part of the index itself.
create table foo (
id integer not null,
yesno boolean not null,
extra text
);
Create unique index foo_uk
on foo (id, yesno)
include (extra);
You did not indicate what Postgres version you have, so this may not be appropriate, as you need at least version 11.
I am looking for some solution for my next use-case in postgres:
I have a table (tasks) that can belong to a user (another table) or a company (another table), it should belong to one of the two tables, that means that I should have nullable foreign keys but also I should check that on Insert then one and only one of those should be filled. How can I make this?
Adding nullable columns (lets say user_id and company_id) with corresponding FOREIGN KEY is correct.
You can add a check-constraint like this (to do it in the CREATE TABLE statement, you can list it "like a column" and start at CONSTRAINT):
ALTER TABLE tasks ADD CONSTRAINT tasks_fk_check
CHECK (
(user_id IS NOT NULL AND company_id IS NULL)
OR
(user_id IS NULL AND company_id IS NOT NULL)
)
;
There are some other possibilities like (user_id IS NULL) <> (company_id IS NULL) to express the XOR property. You can choose them as condition as well.
For further information, have a look into the documentation:
https://www.postgresql.org/docs/current/sql-altertable.html
https://www.postgresql.org/docs/current/sql-createtable.html
https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTS
You can create a function that counts the number of null values in a VARIADAC parameter list. Then create a check constraint accessing that function.
If this is an isolated use case then this is not necessary the best approach, but it is a generalized approach for requiring a certain number of nulls from a set of columns.
--setup create test table
create table task( id serial, user_id integer, company_id integer);
-- create function to count number of nulls in VARIADIC parameter
create or replace function num_of_nulls(VARIADIC integer[])
returns bigint
language sql immutable
as $$
with each_item as (select unnest($1) itm)
select sum(case when itm is null then 1 else 0 end) from each_item;
$$;
-- add check constraint
alter table task add constraint one_and_only_one_must_be_null check (num_of_nulls(user_id,company_id) = 1);
-- test
-- valid
insert into task(user_id,company_id)
values (1,null), (null,1);
select * from task;
-- invalid (must be run separately)
insert into task(user_id,company_id)
values (null,null);
insert into task(user_id,company_id)
values (2,2);
This question already has answers here:
How can you represent inheritance in a database?
(7 answers)
Closed 3 years ago.
I have a table in Postgres which contains Things. Each of these Things can be of 1 of 3 types:
is a self contained Thing
is an instance of a SuperThingA
is an instance of a SuperThingB.
Essentially, in object terms, there's an AbstractThing, extended in
different ways by SuperThingA or SuperThingB and all the records on
the Thing table are either unextended or extended in 1 of the 2
ways.
In order to represent this on the Thing table, I have a number of fields which are common to Things of all types, and I have 2 optional FK reference columns into the SuperThingA and SuperThingB tables.
Ideally, I would like a "FK IF NOT NULL" constraint on each the two, but this doesn't appear to be possible; as far as I can see, all I can do is make both fields nullable and rely on the using code to maintain the FK relationships, which is pretty sucky. This seems to be doable in other databases, for example SQL Server, as per SQL Server 2005: Nullable Foreign Key Constraint, but not any way that I've found so far in PG
How else can I handle this - an insert/update trigger which checks the values when either of those fields is not null and checks the value is present on whichever parent table? That's maybe doable on a small parent table with limited inserts on the Thing table (which, in fairness, is largely the case here - no more than a couple of hundred records in each of the parent tables, and small numbers of inserts on the Thing table), but in a more general case, would be a performance black hole on the inserts if one or both parent table were large
This is not currently enforced with a FK relationship. I've reviewed the PG docs, and it seem pretty definitive that I can't have an optional FK relatioship (which is understandable). It leaves me with a table definition something like this:
CREATE TABLE IF NOT EXISTS Thing(
Thing_id int4 NOT NULL,
Thing_description varchar(40),
Thing_SuperA_FK int4,
Thing_SuperB_FK char(10),
CONSTRAINT ThingPK PRIMARY KEY (Thing_id)
)
;
Every foreign key on a nullable column is only enforced when the value is non-null. This is default behavior.
create table a (
id int4 not null primary key
);
create table b (
id int4 not null primary key,
a_id int4 references a(id)
);
In the example table b has an optional reference to table a.
insert into a values(1); -- entry in table a
insert into b values (1, 1); -- entry in b with reference to a
insert into b values (2, null); -- entry in b with no reference to a
Depending on your use case it also might make sense to reverse your table structure. Instead of having the common table pointing to two more specialized tables you can have it the other way around. This way you avoid the non-null columns entirely.
create table common(
id int4 primary key
-- all the common fields
);
create table special1(
common_id int4 not null references common(id)
-- all the special fields of type special1
);
create table special2(
common_id int4 not null references common(id)
-- all the special fields of type special2
);
You need your SuperN_FK fields defined as nullable foreign keys, then you'll need check constraint(s) on the table to enforce the optional NULLability requirements.
CREATE TABLE Things
( ID int primary key
, col1 varchar(1)
, col2 varchar(1)
, SuperA_FK int constraint fk_SuperA references Things(ID)
, cola1 varchar(1)
, constraint is_SuperA check ((SuperA_FK is null and cola1 is null) or
(SuperA_FK is not null and cola1 is not null))
, SuperB_FK int constraint fk_SuperB references Things(ID)
, colb1 varchar(1)
, constraint is_SuberB check ((SuperB_FK is null and colb1 is null) or
(SuperB_FK is not null))
, constraint Super_Constraint check (
case when SuperA_FK is not null then 1 else 0 end +
case when SuperB_FK is not null then 1 else 0 end
<= 1 )
);
In the above example I've split the check constraints up for ease maintenance. The two is_SuperN constraints enforce the NULL requirements on the FK and it's related detail columns, either all NULLs or the FK is not null and some or all of the detail columns are not null. The final Super_Constraint ensures that at most one SuperN_FK is not null.
This is one strange, unwanted behavior I encountered in Postgres:
When I create a Postgres table with composite primary keys, it enforces NOT NULL constraint on each column of the composite combination.
For example,
CREATE TABLE distributors (m_id integer, x_id integer, PRIMARY KEY(m_id, x_id));
enforces NOT NULL constraint on columns m_id and x_id, which I don't want!
MySQL doesn't do this. I think Oracle doesn't do it as well.
I understand that PRIMARY KEY enforces UNIQUE and NOT NULL automatically but that makes sense for single-column primary key. In a multi-column primary key table, the uniqueness is determined by the combination.
Is there any simple way of avoiding this behavior of Postgres? When I execute this:
CREATE TABLE distributors (m_id integer, x_id integer);
I do not get any NOT NULL constraints of course. But I would not have a primary key either.
If you need to allow NULL values, use a UNIQUE constraint (or index) instead of a PRIMARY KEY (and add a surrogate PK column - I suggest a serial or IDENTITY column in Postgres 10 or later).
Auto increment table column
A UNIQUE constraint allows columns to be NULL:
CREATE TABLE distributor (
distributor_id GENERATED ALWAYS AS IDENTITY PRIMARY KEY
, m_id integer
, x_id integer
, UNIQUE(m_id, x_id) -- !
-- , CONSTRAINT distributor_my_name_uni UNIQUE (m_id, x_id) -- verbose form
);
The manual:
For the purpose of a unique constraint, null values are not considered equal, unless NULLS NOT DISTINCT is specified.
In your case, you could enter something like (1, NULL) for (m_id, x_id) any number of times without violating the constraint. Postgres never considers two NULL values equal - as per definition in the SQL standard.
If you need to treat NULL values as equal (i.e. "not distinct") to disallow such "duplicates", I see two three (since Postgres 15) options:
0. NULLS NOT DISTINCT
This option was added with Postgres 15 and allows to treat NULL values as "not distinct", so two of them conflict in a unique constraint or index. This is the most convenient option, going forward. The manual:
That means even in the presence of a unique constraint it is possible
to store duplicate rows that contain a null value in at least one of
the constrained columns. This behavior can be changed by adding the
clause NULLS NOT DISTINCT ...
Detailed instructions:
Create unique constraint with null columns
1. Two partial indexes
In addition to the UNIQUE constraint above:
CREATE UNIQUE INDEX dist_m_uni_idx ON distributor (m_id) WHERE x_id IS NULL;
CREATE UNIQUE INDEX dist_x_uni_idx ON distributor (x_id) WHERE m_id IS NULL;
But this gets out of hands quickly with more than two columns that can be NULL. See:
Create unique constraint with null columns
2. A multi-column UNIQUE index on expressions
Instead of the UNIQUE constraint. We need a free default value that is never present in involved columns, like -1. Add CHECK constraints to disallow it:
CREATE TABLE distributor (
distributor serial PRIMARY KEY
, m_id integer
, x_id integer
, CHECK (m_id <> -1)
, CHECK (x_id <> -1)
);
CREATE UNIQUE INDEX distributor_uni_idx
ON distributor (COALESCE(m_id, -1), COALESCE(x_id, -1));
When you want a polymorphic relation
Your table uses column names that indicate that they are probably references to other tables:
CREATE TABLE distributors (m_id integer, x_id integer);
So I think you probably are trying to model a polymorphic relation to other tables – where a record in your table distributors can refer to one m record xor one x record.
Polymorphic relations are difficult in SQL. The best resource I have seen about this topic is "Modeling Polymorphic Associations in a Relational Database". There, four alternative options are presented, and the recommendation for most cases is called "Exclusive Belongs To", which in your case would lead to a table like this:
CREATE TABLE distributors (
id serial PRIMARY KEY,
m_id integer REFERENCES m,
x_id integer REFERENCES x,
CHECK (
((m_id IS NOT NULL)::integer + (x_id IS NOT NULL)::integer) = 1
)
);
CREATE UNIQUE INDEX ON distributors (m_id) WHERE m_id IS NOT NULL;
CREATE UNIQUE INDEX ON distributors (x_id) WHERE x_id IS NOT NULL;
Like other solutions, this uses a surrogate primary key column because primary keys are enforced to not contain NULL values in the SQL standard.
This solution adds a 4th option to the three in #Erwin Brandstetter's answer for how to avoid the case where "you could enter something like (1, NULL) for (m_id, x_id) any number of times without violating the constraint." Here, that case is excluded by a combination of two measures:
Partial unique indexes on each column individually: two records (1, NULL) and (1, NULL) would not violate the constraint on the second column as NULLs are considered distinct, but they would violate the constraint on the first column (two records with value 1).
Check constraint: The missing piece is preventing multiple (NULL, NULL) records, still allowed because NULLs are considered distinct, and anyway because our partial indexes do not cover them to save space and write events. This is achieved by the CHECK constraint, which prevents any (NULL, NULL) records by making sure that exactly one column is NULL.
There's one difference though: all alternatives in #Erwin Brandstetter's answer allow at least one record (NULL, NULL) and any number of records with no NULL value in any column (like (1, 2)). When modeling a polymorphic relation, you want to disallow such records. That is achieved by the check constraint in the solution above.