PostgreSQL a temporary tabulky a trideni

[Karel Zak]

On Wed, Feb 25, 2004 at 03:38:53PM +0100, Honza Pazdziora wrote:
> 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.

 Hmm, pokud  je mi znamo  tak zadny  standard nic takoveho  nedefinuje a
 proste v  PostgreSQL plati,  ze docasnost  je dana  prave session. IMHO
 todle je to co jsem nedavno  kritizovali u debaty s xbase -- ocekavani,
 ze  "spravne" je  to na  co jsem  doposud navyknuty. Treba  me soucasne
 chovani vyhovuje.

> 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

 Ja osobne PLSQL povazuji za pokus jak  tem co se jednou naucili SQL dat
 moznost  delat v  "temer  SQL"  to co  SQL  neumi. Pokud  to srovnam  s
 libovolnym jinym  jazykem tak je  to dost krkolomny  a ja osobne  v tom
 pisu jen nekolikaradkove veci.

 Jinak uznavam, ze Oracle je v na tom s funkcema lepe.

> 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

 Jde pomoci  SET SESSION  AUTHORIZATION <user> prepinat  pod superuserem
 na  jine  uzivatele. Funkce  getpgusername()  pak  vraci  jmeno  usera.
 Pochopitelne v rade pripadu kde interface_user != DB_user je to na nic.

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

 Takze nakonec  to reseni ma a  jedina vada na krase  je nutnost zjistit
 jsem-li prvni v  dane session nebo ne -- coz  muze celkem snadno udelat
 klient co  zaklada tu session  a po  navazani spojeni mimo  jinych veci
 nainicializuje i  tu potrebnou  temp tabulku. Ty  rutiny co  tu tabulku
 pouzivaji nic zjistovat nemuseji. IMHO je to problem logiky aplikace.

> A co treba ruzna trideni? Jak se to da v PostgreSQL rozumne

 Ano to je vetsi problem.

> 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

 Jo, ale to  znamena vykaslat se na systemove locales  a udelat vlastni.
 Coz uz v konferencich PostgreSQL zaznelo a podle mne to tak i dopadne.

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

 Pouzivani ruznych locales neni nesmysl a  urcite se o tom uvazuje.  Jen
 proste udelat nejake systemove reseni neni uplne trivialni a pri vyvoji
 PostgreSQL se vetsinou jine reseni  nedelaji, a nez nejaky necisty hack
 tak radeji nekolik release nic...

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/