Re: Bulkloading using COPY - ignore duplicates?
От | Lee Kindness |
---|---|
Тема | Re: Bulkloading using COPY - ignore duplicates? |
Дата | |
Msg-id | 15288.29239.825682.850298@elsick.csl.co.uk обсуждение исходный текст |
Ответ на | Re: Bulkloading using COPY - ignore duplicates? (Justin Clift <justin@postgresql.org>) |
Список | 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 по дате отправления: