Re: Duplicates Processing - Mailing list pgsql-sql

From Gary Chambers
Subject Re: Duplicates Processing
Date
Msg-id AANLkTinr=cNsOeMGfOAjg5ncWhQ9p4RbpfyaoV1YN66T@mail.gmail.com
Whole thread Raw
In response to Re: Duplicates Processing  (Tim Landscheidt <tim@tim-landscheidt.de>)
Responses Re: Duplicates Processing  (Rob Sargent <robjsargent@gmail.com>)
List pgsql-sql
Tim,

Thanks for taking the time to reply!

> | INSERT INTO substitutes ([...])
> |   SELECT [...] FROM
> |     (SELECT *,
> |             ROW_NUMBER() OVER (PARTITION BY wattage, tolerance, temperature
> |                         ORDER BY part_number) AS RN
> |      FROM parts) AS SubQuery
> |   WHERE RN > 1;

> | DELETE FROM parts
> | WHERE primary_key IN
> |   (SELECT primary_key FROM
> |     (SELECT *,
> |             ROW_NUMBER() OVER (PARTITION BY wattage, tolerance, temperature
> |                                ORDER BY part_number) AS RN
> |      FROM parts) AS SubQuery
> |    WHERE RN > 1);

You have solved the problem precisely as I described it.  In my haste
to make the request for assistance, I omitted one critical piece of
information that may call into question my data model.  In its current
state, my substitute parts table contains only the part number (the
"new" one, so-to-speak), a foreign key reference to the original parts
table, and some location data (which is also in the original parts
table).  Is there any advice you can offer in light of what I have
just described? I apologize for the oversight.

-- Gary Chambers


pgsql-sql by date:

Previous
From: Tim Landscheidt
Date:
Subject: Re: Duplicates Processing
Next
From: Rob Sargent
Date:
Subject: Re: Duplicates Processing