From: | Nico Williams <nico(at)cryptonector(dot)com> |
---|---|
To: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] WIP Add ALWAYS DEFERRED option for constraints |
Date: | 2017-10-03 20:22:37 |
Message-ID: | 20171003202236.GP1251@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 03, 2017 at 10:10:59PM +0200, Andreas Joseph Krogh wrote:
> +1.
>
> While we're in deferrable constraints land...; I even more often need
> deferrable conditional unique-indexes.
> In PG you now may have:
> ALTER TABLE email_folder ADD CONSTRAINT some_uk UNIQUE (owner_id, folder_type,
> name) DEFERRABLE INITIALLY DEFERRED;
>
> But this isn't supported:
> CREATE UNIQUE INDEX some_uk ON email_folder(owner_id, folder_type, name) WHERE
> parent_id IS NULL DEFERRABLE INITIALLY DEFERRED;
>
> Are there any plans to support this?
Not by me, but I can take a look and, if it is trivial, do it. At a
quick glance it does look like it should be easy enough to do it, at
least to get started on a patch.
If I can get some help with my current patch, I'll take a look :)
But yes, I'd like to have full consistency between CREATE and ALTER.
Everything that one can do with CREATE should be possible to do with
ALTER, including IF NOT EXISTS.
Nico
--
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-10-03 20:34:38 | Re: datetime.h defines like PM conflict with external libraries |
Previous Message | Andreas Joseph Krogh | 2017-10-03 20:10:59 | Re: [PATCH] WIP Add ALWAYS DEFERRED option for constraints |