Re: [GENERAL] upsert functionality

On 1/22/2014 10:21 AM, joocom wrote: Some days ago, i had to to implement an upsert and used a a/LOCK TABLE/ to prevent the race conditions. Working fine for the moment. http://www.joocom.de/blog/postgresql-insert-und-update-in-einem-statement/

Re: [GENERAL] upsert functionality

Some days ago, i had to to implement an upsert and used a a /LOCK TABLE/ to prevent the race conditions. Working fine for the moment. http://www.joocom.de/blog/postgresql-insert-und-update-in-einem-statement/ -- View

Re: [GENERAL] upsert functionality

Thank you for true response will try out. Sajeev On 5/16/13 10:27 AM, "Steven Schlansker" wrote: > >On May 15, 2013, at 11:52 PM, Thomas Kellerer wrote: > >> Sajeev Mayandi, 16.05.2013 07:01: >>> Hi, >>> >>> Our company is planning to move to postreSQL. We were initially using >>> sybase wher

Re: [GENERAL] upsert functionality

On May 15, 2013, at 11:52 PM, Thomas Kellerer wrote: > Sajeev Mayandi, 16.05.2013 07:01: >> Hi, >> >> Our company is planning to move to postreSQL. We were initially using >> sybase where upsert functionality was available using "insert on >> existing update" clause. I know there multiple ways

Re: [GENERAL] upsert functionality

Sajeev Mayandi, 16.05.2013 07:01: Hi, Our company is planning to move to postreSQL. We were initially using sybase where upsert functionality was available using "insert on existing update" clause. I know there multiple ways to fix this using RULE or separate function in postgresql. But I woul

[GENERAL] upsert functionality

Hi, Our company is planning to move to postreSQL. We were initially using sybase where upsert functionality was available using "insert on existing update" clause. I know there multiple ways to fix this using RULE or separate function in postgresql. But I would like to know which version of p

Re: [GENERAL] Upsert Functionality using CTEs

> > > I read it that he has multiple sales from the same person? In which case > pretending that the two sales were from different people isn't the correct > result at all. Actually it turns out that both cases exist. > > I may be missing the point of the query, but wasn't it to add an entry for

Re: [GENERAL] Upsert Functionality using CTEs

On 11 February 2013 07:47, Alban Hertroys wrote: > On Feb 11, 2013, at 2:23, Tim Uckun wrote: > > > This works pretty good except for when the top 100 records have > > duplicated email address (two sales for the same email address). > > > > I am wondering what the best strategy is for dealing wi

Re: [GENERAL] Upsert Functionality using CTEs

> The best strategy is fixing your data-model so that you have a unique key. As > you found out already, e-mail addresses aren't very suitable as unique keys > for people. For this particular case I'd suggest adding a surrogate key. > > Alternatively, you might try using (first_name, email) as yo

Re: [GENERAL] Upsert Functionality using CTEs

On Feb 11, 2013, at 2:23, Tim Uckun wrote: > This works pretty good except for when the top 100 records have > duplicated email address (two sales for the same email address). > > I am wondering what the best strategy is for dealing with this > scenario. Doing the records one at a time would wo

Re: [GENERAL] Upsert Functionality using CTEs

On Sun, Feb 10, 2013 at 5:23 PM, Tim Uckun wrote: > This works pretty good except for when the top 100 records have > duplicated email address (two sales for the same email address). How is it assumed to work when the migrating email already exists in people? > > I am wondering what the best str

[GENERAL] Upsert Functionality using CTEs

I am using a query like this to try and normalize a table. WITH nd as (select * from sales order by id limit 100), people_update as (update people p set first_name = nd.first_name from nd where p.email = nd.email returning nd.id), insert into people (first_name, email, created_at, updated_at)