or default?
The MySQL documentation is mostly due to INSERT...ON DUPLICATE UPDATE
completely breaking their statement-based replication. I accept that
there are other hazards, but it's difficult to have a fully general
syntax that indicates user intent WRT the unique index to merge on.
--
Peter
On Tue, Sep 30, 2014 at 12:37 AM, Anssi Kääriäinen
wrote:
> The main point is that having WITHIN PRIMARY KEY syntax would make usage
> of this feature a lot easier for us.
I was thinking about doing that anyway.
--
Peter Geoghegan
--
You received this message because you are subscri
think that there is an
incredible amount of misinformation about this topic floating around.
The various vendors that have a MERGE feature should have clearly
indicated that MERGE isn't useful for implementing an UPSERT, but they
didn't, and so the problem persists.
--
Peter Geoghegan
-
-insert-into-a-table/2249#2249
Would you be happier with that?
--
Peter Geoghegan
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving e
antees, and they're both non-standard.
[1]
http://www.postgresql.org/message-id/flat/CAM3SWZRP0c3g6+aJ=yydgyactzg0xa8-1_fcvo5xm7hrel3...@mail.gmail.com#CAM3SWZRP0c3g6+aJ=yydgyactzg0xa8-1_fcvo5xm7hrel3...@mail.gmail.com
--
Peter Geoghegan
--
You received this message because you are su
On Sat, Sep 27, 2014 at 6:33 PM, Peter Geoghegan wrote:
> The statement-level trigger stuff (i.e. the idea that ON CONFLICT
> UPDATE never fires an UPDATE statement level trigger) is for
> consistency with user-defined rules, where we're really compelled to
> have INSERT...ON CON
that that isn't a very satisfactory state of affairs for people
who are using per-statement triggers for auditing and things like
that, and I wouldn't be surprised if that was revised.
--
Peter Geoghegan
--
You received this message because you are subscribed to the Google Groups
"Dja
ut
which unique index I mean"? It turns out that that's quite ticklish in
certain edge cases (e.g. partial unique indexes with BEFORE triggers).
We might come up with a better way that's fully general, but I'm not
holding my breath.
> I think even under MySQL it doesn't use
id/CAM3SWZRvkCKc=1Y6_Wn8mk97_Vi8+j-aX-RY-=msrjvu-ec...@mail.gmail.com
You'll need to build PostgreSQL from the git master branch (which
includes dependencies on things like Flex and Bison), with the patch
set applied. There are guides to doing this on the internet, including
this one: http://
