Re: checking update/insert return

Поиск
Список
Период
Сортировка
От Andrew McMillan
Тема Re: checking update/insert return
Дата
Msg-id 1073385037.4518.37.camel@kant.mcmillan.net.nz
обсуждение исходный текст
Ответ на Re: checking update/insert return  ("Marcus Andree S. Magalhaes" <marcus.magalhaes@vlinfo.com.br>)
Список pgsql-novice
On Tue, 2004-01-06 at 11:40, Marcus Andree S. Magalhaes wrote:
> > Hi,
> >
> > Why do you not use the serial data type : SERIAL ?
> >
>
> I must guarantee to the client-side that the ID field
> has no holes....

If you _really_ have to do that, then the only way [I have thought of
over the years] to do it in a transaction safe manner is to pre-allocate
numbers, creating records (just the ID number) in a second table.  Like
pulling raffle tickets out of a book.

Then, when you want a number, you:

BEGIN
  SELECT first unused pre-allocated number FOR UPDATE
  DELETE the pre-allocated number
  INSERT empty 'it-didn't-happen-yet' record with pre-allocated number
COMMIT

BEGIN
  ...
  do other important stuff
  ...
COMMIT

Then, if you roll back the first transaction, the DELETE never happened,
and the INSERT never happened, so the next transaction comes along and
uses that code.

If you roll back the second transaction, then you are still left with an
'empty' record in your table, but there _is_ a record there.  You could
either (a) leave it like that, and be happy, or (b) have a process which
goes along later and removes them while re-pre-allocating the number,
which I would say is probably more pain than it's worth.  Of course the
whole thing is more pain than it's worth, really :-)

Of course something this does not address is _ordering_ of these
records, but you can't guarantee ordering on a multi-user system anyway
unless you make it stop being multi-user for a while.

In the past when people have asked me for this "every code is used"
approach (usually accountants) I've told them "No!", and then baffled
them with justification about how hard it is until their eyes glazed
over.

Then, of course, when I've got them off my back I just can't help
worrying at the problem until I get some sort of half-assed solution
together :-)

Cheers,
                    Andrew McMillan.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053,  Manners St,  Wellington
WEB: http://catalyst.net.nz/             PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201       MOB: +64(21)635-694      OFFICE: +64(4)499-2267
                     The Killer Ducks are coming!!!

-------------------------------------------------------------------------

В списке pgsql-novice по дате отправления:

Предыдущее
От: vhikida@inreach.com
Дата:
Сообщение: Re: postgresql in windows
Следующее
От: Martin Hampl
Дата:
Сообщение: Disk usage