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