Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace

> INSERT INTO temp_sales
> SELECT DISTINCT on key supplysources.supplysource,
> incharges.supply, targets.target, incharges.saledate,
> incharges.supplyunit, '', incharges.quantity, incharges.company,
> incharges.costcntr, 'Replenish', incharges.price, '','','', 0,
> text(supplysources.supplysource)||
> text(incharges.supply)||
> text(targets.target)||
> text(incharges.saledate) as key
> FROM supplysources, incharges, targets WHERE
> supplysources.warehouse = incharges.warehouse AND
> (targets.site,targets.area) = (incharges.site,incharges.area);
>
> What happens is that a large charges file which is transferred to
> a mainframe ERP application is first brought into PostgreSQL.
> Depending upon certain race conditions, duplicate "sales" records
> can appear in the data file. We use DISTINCT ON to pick (as you
> point out) an arbitrary record when duplicates appear. I suppose
> we could do a DELETE ... WHERE NOT EXISTS after the import. Using
> DISTINCT ON just saves a step. I don't have any arguments beyond
> the grounds that we're using it in existing code as a duplicate
> record filter - :-(

Why not just throw a NOTICE and keep the feature.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026