On Mon, Oct 06, 2003 at 18:56:28 +0200,
papapep <papapep@gmx.net> wrote:
>
> I'm very sorry, but I think I don't understand completely what you mean.
> Perhaps you suggest to insert the whole data in an initial temporary
> table and verify the duplicates in the temporary table before
> transfering the "good" rows to the real table? If so, how should I do
Yes. That allows you to use SQL to handle the duplicates which is probably
going to be simpler than writing a trigger. You can also use copy to
load the temp table which will be faster than using inserts.
> the duplicates control in the temp table? (for me is as difficult as my
> first question :-( )
> Consider that the primary key that we use to see if the row is
> duplicated, or not, is a 5 fields key (it has to be so, is a complex
> data to filter).
You haven't given us a rule to use when deciding which tuples to remove
when a duplicate is detected. Without such a rule we can't give you
detailed instructions on how to remove the duplicates. Having a 5
column primary key doesn't make the problem significantly more difficult
to solve, it mostly just adds a small amount of typing.