Insert v PostgreSQL 7.1.3

Karel Zak zakkr na zf.jcu.cz
Středa Únor 6 11:40:36 CET 2002


On Wed, Feb 06, 2002 at 11:26:22AM +0100, Ing. Pavel PaJaSoft Janousek wrote:
> Karel Zak wrote:
> >  Kazdy backend si allokuje jedno cislo (nebo vice zalezi na nastaveni
> >  CACHE v CREATE SEQUENCE). Pokud nema zadne cislo "zamluvene" tak se
> 
> 	Backend = jedna konexe do jedne databaze (mimochodem, pokud na urovni
> ESQL udelam konexi k vice databazim, porad to bezi po jednom backendu?),
> at si rozumime, ju?

 Dobra rikejme tomu treba session. Proste pro daneho klienta a danou
 DB (ostatne jedena konexe ma vzdy jen jednu DB:-)

> 	V tom pripade select nextval a nasledne select curval mi daji to same
> cislo (ano, priznavam, ze jsem to v prvni uvaze prohodil, nicmene
> myslenka je porad stejna) v ramci jednoho backendu. Pokud tedy sam

 Ano presne. Proto jsme rekl, ze dobre reseni je ta modifikace tveho
 puvodniho napadu. Tedy INSERT ktery si sam zavola nextval() a ja se
 pak pomoci currval() podivam na to cislo.

> nejsem truhlik a nemam nejaka zbloudila vlakna, pak to funguje, OK?
> Nikdy jsem nikde netvrdil, ze musim v ramci jednoho backendu dostat

 To netvrdil nikdo.

> vzestupnou radu bez 'mezer', nicmene pokud by neplatilo ano toto, tak uz
> nevim... - pochopil jsem to mimotransakcni asi takto:
> 
> curval = 100
> 
> B1			B2
> nextval = 101
> curval = 101
> 			nextval = 102
> nextval = 103
> 			curval = 103!!!
> 
> Verim, ze ve skutecnosti je ten posledni curval porad 102, pokud ne,
> tak...'-)

  Ano 102. Proto jsem si dovolil tvrdit, ze ta modifikace tveho napadu
  je funkcni a IMHO se mi snad povede presvedcit i Radka Kanovskeho
  :-)

  Jedine nedopatreni byla ta poslopnost v tom jak se volal currval a
  nextval.

        Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz


Další informace o konferenci Test