Re: Bulkloading using COPY - ignore duplicates? - Mailing list pgsql-hackers

From Lee Kindness
Subject Re: Bulkloading using COPY - ignore duplicates?
Date
Msg-id 15288.29239.825682.850298@elsick.csl.co.uk
Whole thread Raw
In response to Re: Bulkloading using COPY - ignore duplicates?  (Justin Clift <justin@postgresql.org>)
List pgsql-hackers
Justin Clift writes:> Lee Kindness wrote:> >  WITH ON_DUPLICATE = CONTINUE|TERMINATE (or similar)> I would suggest :>
WITHON_DUPLICATE = IGNORE|TERMINATE> purely for easier understanding, given there is no present standard nor> other
databases'syntax to conform to.
 

Personally I don't see the need, and think that 'COPY FROM' could well
just go with the new semantics...

Onto an implementation issue - _bt_check_unique() returns a
TransactionId, my plans were to return NullTransactionId on a
duplicate key but naturally this is used in the success
scenario. Looking in backend/transam/transam.c I see:
TransactionId NullTransactionId = (TransactionId) 0;TransactionId AmiTransactionId = (TransactionId) 512;TransactionId
FirstTransactionId= (TransactionId) 514;
 

From this I'd gather <514 can be used as magic-values/constants, So
would I be safe doing:
TransactionId XXXXTransactionId = (TransactionId) 1;

and return XXXXTransactionId from _bt_check_unique() back to
_bt_do_insert()? Naturally XXXX is something meaningful. I presume all
I need to know is if 'xwait' in _bt_check_unique() is ever '1'...

Thanks,

--Lee Kindness, Senior Software EngineerConcept Systems Limited.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bulkloading using COPY - ignore duplicates?
Next
From: Justin Clift
Date:
Subject: Re: Spinlock performance improvement proposal