its about F*G time
Postgres gets support for upsert
101–110 of 114 posts
Re: Postgres gets support for upsert
#102Earlier quoted context omitted.
Yeah, it is the same as INSERT ... ON DUPLICATE KEY UPDATE, and similar to REPLACE in MySQL. Exciting to see it in Postgres!
I think the way MySQL works in doing "INSERT ... ON DUPLICATE KEY UPDATE" is to delete the old row and insert a new row if there's an auto incremental column (mostly it's ID column). Being curious if Postgres works the same way in this regard.
No, the auto increment columns are maintained as is.
Re: Postgres gets support for upsert
#103Earlier quoted context omitted.
I think the way MySQL works in doing "INSERT ... ON DUPLICATE KEY UPDATE" is to delete the old row and insert a new row if there's an auto incremental column (mostly it's ID column). Being curious if Postgres works the same way in this regard.
No, the auto increment columns are maintained as is.
That's great. Otherwise, it just wastes IDs unless one figures out a workaround for it.
Re: Postgres gets support for upsert
#104I know it doesn't matter to some developers out there, but for me, the only thing left is the ability to add a column after another one. Even if it's only logical order, it's easier for me to read a table structure when fields are ordered nicely.
Work on this started recently, but since it is an open source project there is no way to know if this will make it to 9.6 or not (the work was start too late to get into 9.5).
http://www.postgresql.org/message-id/flat/20141209174146.GP1...
Re: Postgres gets support for upsert
#105Earlier quoted context omitted.
> And if MySQL wasn't robust then YouTube, Facebook, Twitter, Alibaba, LinkedIn etc wouldn't be using it for core parts of their infrastructure. It's definitely robust. Popularity is not an argument for quality. See: crocs, Justin Bieber, PHP. Those companies you mentioned, like many others, probably use it because they're locked in that technology, not because it's a superior one. Just like banks still use COBOL. If…
As an enthusiastic wearer of Crocs I have to interject to point out that there are many different aspects to quality - being robust is just one of them. Being able to easily recruit experts, ease of use, availability and quality of tools in the ecosystem are other measures.
It took me a while to realise the thing you referred to had changed, which led me to google "Crocs experts".
Re: Postgres gets support for upsert
#106Earlier quoted context omitted.
> And if MySQL wasn't robust then YouTube, Facebook, Twitter, Alibaba, LinkedIn etc wouldn't be using it for core parts of their infrastructure. It's definitely robust. Popularity is not an argument for quality. See: crocs, Justin Bieber, PHP. Those companies you mentioned, like many others, probably use it because they're locked in that technology, not because it's a superior one. Just like banks still use COBOL. If…
I never said popularity was an argument for quality. You did. What I am saying is that if MySQL wasn't robust then those companies simply wouldn't be using it. Since at their scale any bug or weakness will manifest at a level far greater than say at a startup. And they have the skills, time and money to choose any technology they wan't so I don't buy your argument that they are "locked in". Some like Facebook and Lin…
> And I never said MySQL was a good idea. You did. I am saying that to claim it is not robust flies in the face of available evidence.
I am glad you mention the word "evidence", since you have provided none so far. An assorted selection of popular, buzz-worthy sites does not qualify as evidence (or lack thereof) of the validity of the technologies they use and endorse.
For contrast, I linked to a really nice post that explains thoroughly why MySQL is not a good idea in the slightest. I would encourage you to read it.
Re: Postgres gets support for upsert
#107Oh happy day. PostgreSQL is the best.
Re: Postgres gets support for upsert
#108Earlier quoted context omitted.
Yeah, it is the same as INSERT ... ON DUPLICATE KEY UPDATE, and similar to REPLACE in MySQL. Exciting to see it in Postgres!
I think the way MySQL works in doing "INSERT ... ON DUPLICATE KEY UPDATE" is to delete the old row and insert a new row if there's an auto incremental column (mostly it's ID column). Being curious if Postgres works the same way in this regard.
No, that's how REPLACE works -- which is a complete pain to be honest! INSERT ... UPDATE works the way you'd hope it would, and keeps the auto inc columns correct.
Re: Postgres gets support for upsert
#109Say goodbye to CRUD. Because 'create' and 'update' are syntactically and semantically the same, right?
Re: Postgres gets support for upsert
#110So to simplify, what I understand is 1. INSERT .. ON CONFLICT is an implementation UPSERT technique 2. MERGE is something meant to be different from UPSERT but has UPSERT feature?
Basically true except for many implementations of MERGE not being concurrency safe, which means you would have to loop anyway on unique violation making it no better than the CTE based techniques that already exist in 9.4.