PostgreSQL a temporary tabulky a trideni

[Honza Pazdziora]

On Wed, Feb 25, 2004 at 03:16:25PM +0100, Karel Zak wrote:
> On Wed, Feb 25, 2004 at 11:31:53AM +0100, Honza Pazdziora wrote:
> > ze temporary tabulka nema per session obsah, ale taky pouze existuje
> > per session. Abys nebyl zklamany.
> 
>  Tomu nerozumim. Obsah tabulky neni per session, ale tabulka samotna 
>  per session je? 

Od temporary tabulky bych tak nejak ocekaval, ze ji jednou vyrobim (to
je DDL operace, takze to by mel delat nekdo s dostatecne vysokymi
pravy), ona bude existovat, ale kazda session bude zacinat s cistym
obsahem. A uzivatele (s DML pravy) v ni budou pracovat. V PostgreSQL
ovsem ta tabulka po skonceni session zmizi.

>  Ostatne stejne zklaman by mohl byt clovek pri prechodu na DB2, Informix
>  nebo na pri prechodu z xbase ;-)  Pro mne je u Oracle zklamanim, ze pri
>  debatach v konferenci nemuzu podivat do zdrojaku jek je tam co udelano.

No, tohle nema byt co zklamanim, protoze tohle jaksi predem vis.
Zatimco PostgreSQL ma podporu spousty proceduralnich jazyku, ale minimalne
v tom "nativnim" (PL/pgSQL) se nedaji pekne udelat promenne pouzitelne
pri behu jednoho databazoveho spojeni (tedy Oracli package).

Abych jen tak neteoretizoval, uvedu priklad, kde to pouzivam a kde mi
to vadi, treba nekdo bude vedet elegantni reseni:

Uzivatele klikaji autentizovane na Webu. Chci u jednotlivych zmen
v databazi logovat, kdo tu zmenu udelal. Do databaze ten aplikacni
server jde pod jednim uzivatelem. Chtel bych nejlepe jeste pred
spustenim toho aplikacniho handleru nastavit nejakou promennou v tom
databazovem spojeni, ktera by se pak pouzila ve vsech tedy insert /
update / delete triggerech jako hodnota prave prihlaseneho vzdaleneho
uzivatele a predala do logovacich tabulek.

Nejblize, jak jsem se dostal k reseni, je pokazde testovat, jestli
uz dana pomocna tabulka existuje (protoze jsem ji mohl zdedit
s presistentnim db spojenim), pokud ne, tak ji vytvorit, commitnout,
ulozit hodnotu, a pouzivat. A ty manipulace s ni musim delat pres
execute '', protoze primy select se chytne na nejaky interni
identifikator, ktery o kousek dal uz neexistuje. Oc jednodussi by
to bylo, kdybych vedel, ze ta tabulka vzdy bude existovat, protoze
jsem ji jednou v ramci vytvareni datoveho schematu vytvoril,
dokonce bych si nad ni mohl udelat primarni klice a foreign klice
a tak, a kazda session by do ni pouze dala aktualni data.

A co treba ruzna trideni? Jak se to da v PostgreSQL rozumne
udelat? Ano, pouziti locales je fajn, jenze co se stane, kdyz
zupgraduju glibc-common a jako na potvoru tam definice locales bude
trosku jina? Rekl bych, ze mi to rozpadne indexy. Nehlede na to, ze by
fakt vcelku rad jednou delal order by anglicky a jednou cesky -- tuhle
se tady na to nekdo ptal a odpoved provest initdb se spravnym
LC_COLLATE neni uplne to prave orechove. V Oraclu je to parametr
klienta (NLS_SORT), menitelny, plus jeste kazdy order by muze pouzit
svoje nls nastaveni. Co PostgreSQL? Skoro uvazuju, ze budu muset
sednout a naportovat do PostgreSQL svou radici rutinu z MySQL.
Alternativne by se to mozna dalo napsat i pomoci strxfrm, aby to bylo
kompatibilni s localovym PostgreSQLim pristupem. Jen me prekvapuje,
ze odpovedi jsou vesmes "udelej spravne initdb", misto aby vyvojari
rekli, ze radit podle ruznych kriterii neni uplne nesmyslny napad
a ze to nema co byt zadratovany parametr databazove instalace.

-- 
------------------------------------------------------------------------
 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.