Skip site navigation (1) Skip section navigation (2)

Re: Bulkloading using COPY - ignore duplicates?

From: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>
To: Justin Clift <justin(at)postgresql(dot)org>
Cc: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bulkloading using COPY - ignore duplicates?
Date: 2001-10-01 13:40:07
Message-ID: 15288.29239.825682.850298@elsick.csl.co.uk (view raw or flat)
Thread:
Lists: pgsql-hackers
Justin Clift writes:
 > Lee Kindness wrote:
 > >  WITH ON_DUPLICATE = CONTINUE|TERMINATE (or similar)
 > I would suggest :
 > WITH ON_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 Engineer
 Concept Systems Limited.

In response to

pgsql-hackers by date

Next:From: Justin CliftDate: 2001-10-01 13:48:19
Subject: Re: Spinlock performance improvement proposal
Previous:From: Justin CliftDate: 2001-10-01 13:37:37
Subject: When scripting, which is better?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group