Say we have users and each user can have multiple email addresses

    user_id integer,
    email_address text,
    is_active boolean

Some sample rows

user_id | email_address | is_active
1       | [email protected]   | t
1       | [email protected]   | f
1       | [email protected]   | f
2       | [email protected]     | t

I want to enforce a constraint that every user has exactly one active address. How can I do this in Postgres? I could do this:

CREATE UNIQUE INDEX "user_email" ON emails(user_id) WHERE is_active=true;

Which would protect against a user having more than one active address, but wouldn't, I believe, protect against all of their addresses being set to false.

If possible I'd prefer to avoid a trigger or a pl/pgsql script, as we don't currently have any of those & it would be difficult to set up. But I would appreciate knowing "the only way to do this is with a trigger or pl/pgsql", if that is the case.


3 Answers 3


You don't need triggers or PL/pgSQL at all.
You don't even need DEFERRABLE constraints.
And you don't need to store any information redundantly.

Include the ID of the active email in the users table, resulting in mutual references. One might think we need a DEFERRABLE constraint to solve the chicken-and-egg problem of inserting a user and his active email, but using data-modifying CTEs we don't even need that.

This enforces exactly one active email per user at all times:

  user_id  serial PRIMARY KEY
, username text NOT NULL
, email_id int NOT NULL  -- FK to active email, constraint added below

  email_id serial PRIMARY KEY
, email    text NOT NULL
, CONSTRAINT email_fk_uni UNIQUE(user_id, email_id)  -- for FK constraint below
ALTER TABLE users ADD CONSTRAINT active_email_fkey
FOREIGN KEY (user_id, email_id) REFERENCES email(user_id, email_id);

Remove the NOT NULL constraint from users.email_id to make it "at most one active email". (You can still store multiple emails per user, but none of them is "active".)

Aside: If (user_id, email) is unique (as can be assumed), you might use email directly instead of email_id ...

You can make active_email_fkey DEFERRABLE to allow more leeway (insert user and email in separate commands of the same transaction), but that's not necessary.

I put user_id first in the UNIQUE constraint email_fk_uni to optimize index coverage. Details:

Optional view:

CREATE VIEW user_with_active_email AS
SELECT * FROM users JOIN email USING (user_id, email_id);

Here's how you insert new users with an active email (as required):

WITH new_data(username, email) AS (
      ('usr1', '[email protected]')   -- new users with *1* active email
    , ('usr2', '[email protected]')
    , ('usr3', '[email protected]')
, u AS (
   INSERT INTO users(username, email_id)
   SELECT n.username, nextval('email_email_id_seq'::regclass)
   FROM   new_data n
INSERT INTO email(email_id, user_id, email)
SELECT u.email_id, u.user_id, n.email
FROM   u
JOIN   new_data n USING (username);

The specific difficulty is that we have neither user_id nor email_id to begin with. Both are serial numbers provided from the respective SEQUENCE. It can't be solved with a single RETURNING clause (another chicken-and-egg problem). The solution is nextval() as explained in detail in the linked answer below.

If you don't know the name of the attached sequence for the serial column email.email_id you can replace:



nextval(pg_get_serial_sequence('email', 'email_id'))

Here's how you add a new "active" email:

   INSERT INTO email (user_id, email)
   VALUES  (3, '[email protected]')
UPDATE users u
SET    email_id = e.email_id
FROM   e
WHERE  u.user_id = e.user_id;

db<>fiddle here
Old sqlfiddle

You might encapsulate the SQL commands in server-side functions if some simple-minded ORM isn't smart enough to cope with this.

Closely related, with ample explanation:

Also related:

About DEFERRABLE constraints:

About nextval() and pg_get_serial_sequence():

  • Can this be applied to 1 to at-least-one relationships? Not 1 -1 as shown in this answer. Apr 30, 2017 at 3:02
  • @CMCDragonkai: Yes. Exactly one active email per user is enforced. Nothing keeps you from adding more (non-active) emails for the same user. If you don't want the special role for the active email, triggers would be a (less strict) alternative. But you have to be careful to cover all updates and deletes. I suggest you ask a question if you need this. Apr 30, 2017 at 3:37
  • Is there any way to delete users without using ON DELETE CASCADE? Just curious (cascading is working fine for now).
    – amoe
    Jul 25, 2017 at 15:38
  • @amoe: There are various ways. Data-modifying CTEs, triggers, rules, multiple statements in the same transaction, ... it all depends on exact requirements. Ask a new question with your specifics if you need an answer. You can always link to this one for context. Jul 29, 2017 at 1:48
  • 1
    @PirateApp: Not sure I understand the question. Please post an actual question with sufficient context. You can always link to this one for context and drop a comment here to link back (and get my attention). Nov 30, 2021 at 23:42

If you can add a column to the table, the following scheme would almost1 work:

    UserID integer NOT NULL,
    EmailAddress varchar(254) NOT NULL,
    IsActive boolean NOT NULL,

    -- New column
    ActiveAddress varchar(254) NOT NULL,

    -- Obvious PK
    CONSTRAINT PK_emails_UserID_EmailAddress
        PRIMARY KEY (UserID, EmailAddress),

    -- Validate that the active address row exists
    CONSTRAINT FK_emails_ActiveAddressExists
        FOREIGN KEY (UserID, ActiveAddress)
        REFERENCES emails (UserID, EmailAddress),

    -- Validate the IsActive value makes sense    
    CONSTRAINT CK_emails_Validate_IsActive
        (IsActive = true AND EmailAddress = ActiveAddress)
        (IsActive = false AND EmailAddress <> ActiveAddress)

-- Enforce maximum of one active address per user
CREATE UNIQUE INDEX UQ_emails_One_IsActive_True_PerUser
ON emails (UserID, IsActive)
WHERE IsActive = true;

Test SQLFiddle

Translated from my native SQL Server, with help from a_horse_with_no_name

As ypercube mentioned in a comment, you could even go further:

  • Drop the boolean column; and
  • Create the UNIQUE INDEX ON emails (UserID) WHERE (EmailAddress = ActiveAddress)

The effect is the same, but it is arguably simpler and neater.

1 The problem is that the existing constraints only ensure that a row referred to as 'active' by another row exists, not that it is also actually active. I don't know Postgres well enough to implement the extra constraint myself (at least not right now), but in SQL Server, it could be done thusly:

    EmailID integer NOT NULL UNIQUE,
    UserID integer NOT NULL,
    EmailAddress varchar(254) NOT NULL,
    IsActive bit NOT NULL,

    -- New columns
    ActiveEmailID integer NOT NULL,
    ActiveIsActive AS CONVERT(bit, 'true') PERSISTED,

    -- Obvious PK
    CONSTRAINT PK_emails_UserID_EmailAddress
        PRIMARY KEY (UserID, EmailID),

    CONSTRAINT UQ_emails_UserID_EmailAddress_IsActive
        UNIQUE (UserID, EmailID, IsActive),

    -- Validate that the active address exists and is active
    CONSTRAINT FK_emails_ActiveAddressExists_And_IsActive
        FOREIGN KEY (UserID, ActiveEmailID, ActiveIsActive)
        REFERENCES emails (UserID, EmailID, IsActive),

    -- Validate the IsActive value makes sense    
    CONSTRAINT CK_emails_Validate_IsActive
        (IsActive = 'true' AND EmailID = ActiveEmailID)
        (IsActive = 'false' AND EmailID <> ActiveEmailID)

-- Enforce maximum of one active address per user
CREATE UNIQUE INDEX UQ_emails_One_IsActive_PerUser
ON emails (UserID, IsActive)
WHERE IsActive = 'true';

This effort improves a little on the original by using a surrogate rather than duplicating the full email address.


The only way to do either of these without schema changes is with a PL/PgSQL trigger.

For the "exactly one" case, you can make the references mutual, with one being DEFERRABLE INITIALLY DEFERRED. So A.b_id (FK) references B.b_id (PK) and B.a_id (FK) references A.a_id (PK). Many ORMs etc cannot cope with deferrable constraints though. So in this case you'd add a deferrable FK from user to address on a column active_address_id, instead of using an active flag on address.

  • 1
    The FK doesn't even have to be DEFERRABLE. Aug 25, 2015 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.