dbTalk Databases Forums  

unique problem

comp.databases.postgresql.general comp.databases.postgresql.general


Discuss unique problem in the comp.databases.postgresql.general forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Joolz
 
Posts: n/a

Default unique problem - 11-01-2004 , 09:13 AM






Hi everyone,

When importing a bunch of data (> 85000 rows) I get an error I can't
explain. The table into which I'm importing has a unique clause on
(code, bedrijf). The rows in the source-table are unique in this
aspect, yet when I do the import I get this "ERROR: duplicate key
violates unique constraint "werknemer_bedrijf_key".

I checked the sourcetable a number of times, even COPYd the relevant
columns to a textfile and did `uniq -d` and `uniq -D` (nothing
non-unique found), tried to delete out non-unique rows (again
nothing found).

Is there a bug in the UNIQUE behaviour? I'm running postgresql
7.4.5-2 (from backports) on a debian stable server. Is there any way
I can DEFER the unique clause, or remove it and put it back later?

Thanks!


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)


Reply With Quote
  #2  
Old   
Michael Fuhr
 
Posts: n/a

Default Re: unique problem - 11-01-2004 , 09:54 AM






On Mon, Nov 01, 2004 at 04:13:43PM +0100, Joolz wrote:
Quote:
When importing a bunch of data (> 85000 rows) I get an error I can't
explain. The table into which I'm importing has a unique clause on
(code, bedrijf). The rows in the source-table are unique in this
aspect, yet when I do the import I get this "ERROR: duplicate key
violates unique constraint "werknemer_bedrijf_key".
How are you importing the data? If you use COPY then the error
should show what line is causing the problem, and if you do individual
INSERTs then your import code should be able to recognize the error.
INSERT...SELECT probably won't identify the duplicate record.

Quote:
I checked the sourcetable a number of times, even COPYd the relevant
columns to a textfile and did `uniq -d` and `uniq -D` (nothing
non-unique found), tried to delete out non-unique rows (again
nothing found).
Did you sort the file before you ran uniq? Duplicate lines need
to be adjacent for uniq to recognize them.

% cat foo
abc
def
abc
% uniq -d foo
% sort foo | uniq -d
abc

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend



Reply With Quote
  #3  
Old   
Tom Lane
 
Posts: n/a

Default Re: unique problem - 11-01-2004 , 11:15 AM



"Joolz" <joolz (AT) arbodienst-limburg (DOT) nl> writes:
Quote:
Is there a bug in the UNIQUE behaviour?
No known bugs, anyway. I'm inclined to guess that your target table has
slightly different datatypes than the source, and that results in equal
values for some reason (such as fractional values being rounded to
integer, or char vs varchar having different ideas about significance of
trailing blanks).

Quote:
Is there any way I can DEFER the unique clause, or remove it and put
it back later?
You can always drop and re-add the constraint ... but I'll be pretty
surprised if that gets around the problem (ie, I bet re-adding the
constraint will fail).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings



Reply With Quote
  #4  
Old   
Joolz
 
Posts: n/a

Default Re: unique problem - 11-02-2004 , 12:33 AM




Tom Lane zei:
Quote:
"Joolz" <joolz (AT) arbodienst-limburg (DOT) nl> writes:
Is there a bug in the UNIQUE behaviour?

No known bugs, anyway. I'm inclined to guess that your target table
has
slightly different datatypes than the source, and that results in
equal
values for some reason (such as fractional values being rounded to
integer, or char vs varchar having different ideas about
significance of
trailing blanks).

Is there any way I can DEFER the unique clause, or remove it and
put
it back later?

You can always drop and re-add the constraint ... but I'll be pretty
surprised if that gets around the problem (ie, I bet re-adding the
constraint will fail).
You're right, I cannot re-ad the contraint. The insert translates a
column with a subselect to another value (with another datatype).
Before the insert / translation the two columns are unique,
afterwards it appears they are not.

I'll go and have a look what's wrong with the subselect.

Thanks for the reactions so far everyone!


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.