On Tue, Sep 30, 2014 at 12:49 AM, Anssi Kääriäinen
wrote:
> Both PostgreSQL's proposed documentation and MySQL's
> existing documentation warn users that it is a bad idea to use this
> feature when multiple unique indexes exists for the table. So, why make
> that behavior default?
The MySQL docum
On Mon, 2014-09-29 at 10:56 +0300, I wrote:
> - Wild suggestion: Maybe it would be better to default to the PRIMARY
> KEY index of the table. If no PK index exists, the user must specify
> which unique index to use. Maybe there shouldn't be a possibility to
> specify more than one unique index?
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 subscribed to the
On Mon, 2014-09-29 at 11:11 -0600, Carl Meyer wrote:
> Of course, it would be better for Django to reliably know index names.
> Even though we don't currently, I'm hopeful that
> https://github.com/django/deps/pull/6 may get us there by the time we
> would be considering these changes anyway, which
On Sep 29, 2014, at 2:46 PM, shmengie <1st...@gmail.com> wrote:
> Merge -- bulk loading foreign data -no guaranty
>
> upsert -- insert or update row w/confidence.
Sounds like a difference without a distinction.
Let spin it a different way: the MERGE syntax, and broad semantic, is fine as
it i
On 09/29/2014 01:56 AM, Anssi Kääriäinen wrote:
> I think we could use UPSERT for our .save() logic. Django's save()
> method is defined as:
> - Insert a row in to the database if there isn't already a matching
> row for the saved model's primary key
> - Otherwise update the row
>
> This is cu
To upsert or to merge. Sparked a lot more emotion than I would have
anticipated.
Both ideas, have similiar functionality, they solve marginally different
problems.
Both have the objective of reducing client server traffic involved with pk.
Merge -- bulk loading foreign data -no guaranty
ups
I think we could use UPSERT for our .save() logic. Django's save()
method is defined as:
- Insert a row in to the database if there isn't already a matching
row for the saved model's primary key
- Otherwise update the row
This is currently implemented as "try to update, if nothing was updated,
On Sun, Sep 28, 2014 at 12:44 PM, Petite Abeille
wrote:
> I would be happier with a clean MERGE statement implementation in Postgres,
> yes. And yes, I have followed Postgres' agonizing debate over the years about
> the subject. But I personally think it has been framed in the wrong light
> si
On Sep 28, 2014, at 12:44 PM, Petite Abeille wrote:
> Postgres has convince itself that it somehow cannot support MERGE. Therefore
> it will not.
There's no question that PostgreSQL could support SQL MERGE. But SQL MERGE is
not what people are asking for when they ask for UPSERT. PostgreS
On Sep 28, 2014, at 9:15 PM, Peter Geoghegan wrote:
> Would you be happier with that?
I would be happier with a clean MERGE statement implementation in Postgres,
yes. And yes, I have followed Postgres' agonizing debate over the years about
the subject. But I personally think it has been fram
On 28 September 2014 19:30, Aymeric Augustin
wrote:
> "Obviously the PostgreSQL project can make its own choices. But I'm surprised
> that you're proposing non-standard syntax and semantics, considering
> PostgreSQL's tradition to comply with SQL standards. Even if you disagree with
> some aspect
On Sun, Sep 28, 2014 at 4:44 AM, Petite Abeille
wrote:
> Again, your house, your choice. But it seems a bit self-indulgent to concoct
> your very own take on MERGE, with baroque syntax, peculiar semantic, and all,
> just because some abstract aspects of the MERGE specification is not to you
> l
On 28 sept. 2014, at 19:57, Simon Riggs wrote:
>> 1) The django-developers mailing list isn't the place to rehash the debate,
>> 2) The disparaging vocabulary you're using isn't acceptable in this forum,
>> 3) Personal attacks based on prejudice will not be tolerated.
>
> Well, for 1) any commen
On 28 September 2014 14:32, Aymeric Augustin
wrote:
> On 28 sept. 2014, at 13:44, Petite Abeille wrote:
>
>> Again, your house, your choice. But it seems a bit self-indulgent to concoct
>> your very own take on MERGE, with baroque syntax, peculiar semantic, and
>> all, just because some abstrac
On Sep 28, 2014, at 3:32 PM, Aymeric Augustin
wrote:
> You're allowed to disagree with that decision, however:
You are right. Apologies about that. Moving along.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)
On Sunday 28 September 2014 09:33:06 Simon Riggs wrote:
> On 28 September 2014 02:22, Shai Berger wrote:
> > Upon reading the docs, I was a little surprised to see that in terms of
> > triggers etc, the operation is always considered an INSERT. I would
> > expect it to be considered an insert for
On 28 sept. 2014, at 13:44, Petite Abeille wrote:
> Again, your house, your choice. But it seems a bit self-indulgent to concoct
> your very own take on MERGE, with baroque syntax, peculiar semantic, and all,
> just because some abstract aspects of the MERGE specification is not to you
> likin
On Sep 28, 2014, at 11:21 AM, Peter Geoghegan wrote:
> On Sun, Sep 28, 2014 at 1:51 AM, Petite Abeille
> wrote:
>> For diversity's sake, and for the record, I, for one, would definitively
>> rather have the standard MERGE statement instead of yet another 'weird'
>> UPSERT concoction peculiar
On Sun, Sep 28, 2014 at 1:51 AM, Petite Abeille
wrote:
> For diversity's sake, and for the record, I, for one, would definitively
> rather have the standard MERGE statement instead of yet another 'weird'
> UPSERT concoction peculiar to Postgres.
A few people have said that, but then when you lo
On Sep 28, 2014, at 1:01 AM, Peter Geoghegan wrote:
> The SQL standard's MERGE statement is kind of weird...
For diversity's sake, and for the record, I, for one, would definitively rather
have the standard MERGE statement instead of yet another 'weird' UPSERT
concoction peculiar to Postgres.
There will be some postgresql specific features in Django 1.8 (at least
array fields, probably also hstore, ranges and jsonb). There are also a
couple of new features which have already landed which leverage postgresql
specific features when present and fall back otherwise (uuid, interval).
I am i
On 28 September 2014 00:01, Peter Geoghegan wrote:
> I am a PostgreSQL major contributor, currently undertaking development
> of a feature sometimes called "UPSERT" for PostgreSQL.
Thanks for posting this Peter.
The feature is under review in the PostgreSQL community and we would
like to solici
On 28 September 2014 02:22, Shai Berger wrote:
> Upon reading the docs, I was a little surprised to see that in terms of
> triggers etc, the operation is always considered an INSERT. I would expect it
> to be considered an insert for BEFORE INSERT or INSTEAD OF INSERT triggers,
> but if conflict
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 CONFLICT UPDATE just
On Sat, Sep 27, 2014 at 6:22 PM, Shai Berger wrote:
> Upon reading the docs, I was a little surprised to see that in terms of
> triggers etc, the operation is always considered an INSERT. I would expect it
> to be considered an insert for BEFORE INSERT or INSTEAD OF INSERT triggers,
> but if confl
Hi Alex,
On Sat, Sep 27, 2014 at 5:48 PM, Alex Gaynor wrote:
> Thanks for reaching out about this!
No problem. I'm not sure if you recall, but we actually met before, in
San Francisco during Waza 2013.
> From the docs, the syntax looks pretty reasonable, it would be nice to see
> what some exam
Hi Peter,
Thanks for asking!
On Sunday 28 September 2014 02:01:59 Peter Geoghegan wrote:
>
> * Would you consider the syntax that I've proposed a good one?
>
Looks pretty reasonable.
> * If it was available, would you use it in future versions of Django?
> Do you think the plugins ecosystem c
Hi Peter,
Thanks for reaching out about this!
On Sat, Sep 27, 2014 at 7:01 PM, Peter Geoghegan wrote:
> Hello,
>
> I am a PostgreSQL major contributor, currently undertaking development
> of a feature sometimes called "UPSERT" for PostgreSQL.
>
> Jacob Kaplan-Moss is an acquaintance and co-work
Hello,
I am a PostgreSQL major contributor, currently undertaking development
of a feature sometimes called "UPSERT" for PostgreSQL.
Jacob Kaplan-Moss is an acquaintance and co-worker, and I know that
it's certainly something that interests him personally - presumably he
has some ideas on how an
30 matches
Mail list logo
