Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!pasteur!eden.Berkeley.EDU!mao
From: mao@eden.Berkeley.EDU (Mike Olson)
Newsgroups: comp.databases
Subject: Re: SQL Duplicate Row Deletion ???
Message-ID: <12437@pasteur.Berkeley.EDU>
Date: 3 Apr 91 23:44:52 GMT
References: <91091.141528SYSPMZT@GECRDVM1.BITNET> <1991Apr3.010838.2063@eng.ufl.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: mao@eden.Berkeley.EDU (Mike Olson)
Organization: University of California, Berkeley
Lines: 20

In <1991Apr3.010838.2063@eng.ufl.edu>, tsao@helios.tcad.ee.ufl.edu ( Tsao)
expresses surprise that ingres permits insertion of duplicate rows, and
asks for

> an example justifying the need for duplicated tuples in a table ?

the reason that all commercial systems allow you to insert duplicates is
that, unless an index exists on the table, every insertion turns into
a scan of the entire table.  dups are bad and everyone admits that, but
nobody seems to be willing to pay the cost of guaranteeing they never happen.

we've also discovered (in postgres) that you don't always know what equality
means for a user-defined data type, so you can't in principle guarantee that
dups never happen without extra work on the part of the user.  actually, it
turns out that type extensibility is pretty hard for a lot of reasons like
this, but that's off-topic...
					mike olson
					postgres research group
					uc berkeley
					mao@postgres.berkeley.edu