posledni automaticky generovany id a prenositelnost

[Honza Pazdziora]

On Tue, Aug 10, 2004 at 10:29:23AM +0200, Zdenek Janis wrote:
> 
> Tak mozna mam jine PG :-) Ale testnete si priklad v priloze. Me se jevi 

Mate stejne PG, coz neznamena, ze stejne jako PG se chovaji vsichni
ostatni a ze se PG bude takto chovat i nadale. :-)

> create or replace function "QQQ"."Blee_Insert"
> (varchar)
> returns bigint as '
> insert into "QQQ"."Blee"
>     ("Neco")
> values
>     ($1);
> select currval(''"QQQ"."Blee_ID_seq"'');
> ' language 'sql';

Pokud tohle zmenite na plpgsql a date si za to select currval nejaky
raise, bude videt, ze se ten trigger Blee_AfterTrig provadi nikoli po
vlozeni toho zaznamu do Blee, ale az po provedeni (na konci provedeni)
Blee_Insert. Nedokazu posoudit, nakolik je to chyba a nakolik chtena
vlastnost PG, to by vedel Karel. Kazdopadne neni mozne spolehat, ze
jine servery budou triggery provadet stejne jako PG, tedy jindy nez
provadeji ten prislusny DML prikaz.

> select "QQQ"."Blee_Insert"(now()::varchar);
> select "QQQ"."Blee_Insert"(now()::varchar);

A co Vam tady da select currval('"QQQ"."Blee_ID_seq"'); ?
Predpokladam, ze 10, coz jaksi hodnota posledniho vlozeneho neni a je
to to, na co jsem upozornoval.

Proc to uvnitr ten funkce funguje je jasne, je to dano (z meho
pohledu dosti zvlastnim) okamzikem volani triggeru v PostgreSQL.

Kazdopade je divne, ze dva currvaly jdouci tesne po sobe (jeden ve
funkci a jeden mimo ni, bez toho, aby byl nejaky jiny netxtval mexi
nimi) vraceji jinou hodnotu, a po provedeni toho Blee_Insert se na
tu hodnotu currvalem nedostanete.

Pouzivejte nextval a nemusime to dal resit. :-)

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.