On Thu, May 7, 2015 at 2:14 PM, Peter Geoghegan wrote:
> The only downside I see is that it might not work in preventing the
> statement from proceeding. In other words, you might have a partial
> unique index style inference clause (i.e. with a predicate) that
> infers a non-partial index, becaus
On Thu, May 7, 2015 at 11:32 AM, Andres Freund wrote:
> Hm. I don't really see a point in allowing it - it seems more likely to
> be a mistake by the user, expecting that the insertion now works
> conflict free. But I don't really care much.
The only downside I see is that it might not work in p
On 2015-05-07 11:16:12 -0700, Peter Geoghegan wrote:
> On Tue, May 5, 2015 at 8:52 AM, Heikki Linnakangas wrote:
> > postgres=# create table foo (id int4);
> > CREATE TABLE
> > postgres=# create unique index foo_y on foo (id) where id > 0;
> > CREATE INDEX
> > postgres=# insert into foo values (-1
On Tue, May 5, 2015 at 8:52 AM, Heikki Linnakangas wrote:
> Why not? I would understand if the specified arbiter constraint is deferred,
> but why does it matter if one of the other constraints is?
This has been fixed since, BTW. We now support relations that happen
to have deferred constraints.
On Tue, May 5, 2015 at 8:52 AM, Heikki Linnakangas wrote:
> I've read through all the error messages in the patch. Some comments:
I'll work through this feedback.
> postgres=# create table foo (id int4);
> CREATE TABLE
> postgres=# create unique index foo_y on foo (id) where id > 0;
> CREATE IND
I've read through all the error messages in the patch. Some comments:
postgres=# create table foo (id int4);
CREATE TABLE
postgres=# create unique index foo_y on foo (id) where id > 0;
CREATE INDEX
postgres=# insert into foo values (-1) on conflict (id) where id > 0 do
nothing;
ERROR: in
