Postgres Pro
Downloads
Home   >   mailing lists

Re: Could be improved point of UPSERT - Mailing list pgsql-hackers

From Yourfriend
Subject Re: Could be improved point of UPSERT
Date
Msg-id CABL_R4P7KVjDV8yNwis-OFp5mrE1+j7TU9pXv2-UPmqMtH34oA@mail.gmail.com
Whole thread Raw
In response to Re: Could be improved point of UPSERT  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Could be improved point of UPSERT  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Tree view
In my example, I just give each record a different ID to access it efficiently.

In our business cases, some times, we also use some prefix letter like 'SO', "PO' combining with the current year, month and then a sequence  
to make a invoice ID,

for example, SO201507_1001, PO201503_1280, etc.

As these IDs would be the most important attribute to the business, so, we hope there is no gap for the IDs.

Regards,

Daojing Zhou.



On Wed, Jul 15, 2015 at 2:33 AM, Peter Geoghegan <pg@heroku.com> wrote:
On Sun, Jul 12, 2015 at 4:09 AM, Yourfriend <doudou586@gmail.com> wrote:
> Suggestion:  When a conflict was found for UPSERT, don't access the
> sequence, so users can have a reasonable list of ID.

This is not technically feasible. What if the arbiter index is a serial PK?

The same thing can happen when a transaction is aborted. SERIAL is not
guaranteed to be gapless.
--
Peter Geoghegan

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Simon Riggs
Date:
Subject: Re: Support for N synchronous standby servers - take 2