Názory k článku Co nového v PostgreSQL 8.0?

Zvlaste konecne dodana podpora tablespace se zda byti extremne potesujici

Nezostáva mi nič iné len si zakričať 3x hurá vývojárom PostgreSQL.

A jedna otázka. OID som v PostgreSQL používal na zistenie ID posledne vloženého riadku tabulky. (nejak takto)

$db_oid = $conn ->Insert_ID();
$sql = "SELECT priloha_id FROM prilohy WHERE oid=".$db_oid;

Síce to môžem používať aj naďalej ale budem musieť pamätať vždy na ...WITH OID; Jestvuje nejaký lepší spôsob, ktorý mi 100% vráti správne ID?

Nepřecházel jste z MySQL? Váš způsob zjištění id je sice docela zajímavý, ale normálně se na to používají sekvence (pri insertu nextval, pak zjistit currval).

A kdyz si mezitim ze stejne sekvence vyzvedne cislo nekdo jiny, tak vrati currval co?

vrati to, co posledni vami volana nextval(). tedy presne to co potrebujete.

To viem ale kdesi bola na tuto temu dlha debata a neutvrdila ma v tom ze pouzivat currval() mi vzdy zabezpeci to spravne id - tusim ze ani transakcia nezabezpeci ze medzitym co volam currval() mi niekto vlozi dalsi riadok...

Nic lepšího nenajdete. Sekvence fungují naprosto perfektně

Ještě zbývá konzervativní metoda nejdřív zavolat nextval a uložit si výsledek do proměnné. V insertu pak explicitně použít na místě ID tuto proměnnou a použít ji i pro jakoukoliv další potřebnou operaci.

Jinak zde je příslušná sekce z manuálu k funkci currval:
Return the value most recently obtained by nextval for this sequence in the current session. (An error is reported if nextval has never been called for this sequence in this session.) Notice that because this is returning a session-local value, it gives a predictable answer even if other sessions are executing nextval meanwhile.

Nicméně právě proto, že se snažím PostgreSQL propagovat mezi stávajícími uživateli MySQL, si myslím, že by bylo hezké mít funkci, která by volání currval zabalila tak, aby se podobalo volání vracejícímu v MySQL naposledy insertované ID. Asi to není problém napsat v plpgsql s využitím informačního schématu.

No, kdyz si prectes navod k sekvencim, tak je tam napsany, ze kazdy proces pouziva vlastni "prostor" sekvence, takze je zaruceno, ze v ramci jedne session dostanes "spravne" currval... Ale pristup MySQL se mi libi vic (s tim serial-id - nebo jak se to jmenuje - jako typ sloupce)

V postgre existuje typ SERIAL a BIGSERIAL, což jsou jakési pseudotypy, které při založení tabulky založí sekvenci a do default hodnoty nastaví nextval...

http://www.postgresql.org/docs/7.4/interactive/datatype.html#DATATYPE-SERIAL

a sakra ted si nejsem jistej jestli curval neni transaction safe, tzn ze vrati posledni nexval v transakci tj volani curval bez predchoziho nextval nevraci nic (nebo chybu)....
mam ted zrovna pgqdmin otevrenej ale mam taky prilis velkej kopr to zkusit... kazdopadne v dokumentaci to bude

do konfiguraku jde napsat ze defaultne se maji vytvaret s oid

Konecne poradny backup.
Konecne bude mozne PostgreSQL nasadit i v narocnejsim prostredi. Tedy az to uzraje - aspon verzi 8.1 .

Uzravani bych se nebal. Transakcni log je zde jiz dlouho a PG je vyvijen pomerne zodpovedne. Do narocnejsiho nasazeni bych sel s 8.0.1 nebo 8.0.2.

no 8.0.x bejvaj vetsinou naky sekurity fixy ne ?
ja sice 8.0 na voknech pouzivam od beta 2 a na linuxu od rc4, ale zalohuju jak splasenej a nemam tam kriticky data.. (jo ty XP mi parkrat spadly do blueskreenu ale pochybuju ze za to muze pg ac to vyloucit nemuzu tak sem to ani nereportoval)
na kriticky data bych cekal jednoznacne na 8.1 (teda jestli se nebude zase menit ARC algoritmus zpatky nebo nekam jinam)

8.0.x budou opravy chyb a to obecne nejen security.

Port na windows:

Although tested throughout our release cycle, the Windows port does not have the benefit of years of use in production environments that PostgreSQL has on Unix platforms. Therefore it should be treated with the same level of caution as you would a new product.

:-)

jo jo :-)) pamatuju tu debatu na mailing listu co tam k tem woknum napsat :-) zvlast tomuv nazor ze slovo instabilita a postgres nesmi bejt v jedny vete :-)
jo PG je super. mam ho moc rad a jedina vec ktera mi na nem vadi je neoptimalizovani opakovanedo volani funkce (stable) v query
typu
select expencive_function(p1, p2) as value
1/expencive_function(p1, p2) as inverted
from table

vyvola pro kazdej radek expencve_function dvakrat i kdyz je stable.

a to je nebrutalnejsi nedostatek kterej vidim v postgresu (plpgsql) jinak sem stastnej jak blecha

Pisalo sa o tom, ze 8.0-ka by uz mala mat v sebe master-master a master-slave replikaciu (implementovany projekt Slony tusim). Je to uz implementovane ?

Slony I je jiz dokoncene, stale vsak jako oddeleny projekt.

ufff konecne ale ze to trvalo, huraaaaaaa

> Nově můžete zapsat:
>
> $$It's the best database server.$$

Takze dalsi moznost na SQL injection jinym zpusobem .... tim horsi ze tradicni addslashes a podobne funkce v jinych jazycich s tim nebudou pocitat ... :o)

Nic vas nenuti vkladat nejaky string primo do query. Klientska knihovna ma API kde lze plne bezpecne posilat data na server mimo query. A nikde neni ani slovo o tom, ze $$ je bezpecnostni zalezitos...

Škoda jen, že to zatím autoři PHP interface nezaregistrovali a neumožnili, aby pg_query() fungovala podobně jako ibase_query().

Ja bych to videl opacne - pokud kazdy retezec do query budete davat stylem:
$secretrandomhash$Zde je nas retezec$secretrandomhash$, tak nikdo nema sanci odhadnout onen hash. Pozor, musi byt opravdu nahodny, ne ze bude natvrdo ve zdrojaku.

Budou subtransakce fungovat i nejak automaticky pro jednotlive SQL prikazy? Nebo bude nutne explicitne delat savepointy? Jde mi o to, aby kdyz vykonam SQL prikaz ktery spadne (treba na cizim nebo unique klici nebo na syntaxi), tak abych mohl normalne pokracovat dal a nedozvedel se, ze musim odrolovat celou transakci.

-Yenya

Zatim to psql urcite neumi. Existuje ale patch pro 8.1. http://candle.pha.pa.us/mhonarc/patches2/msg00025.html

Dost by mne bodlo, kdyby nekdo uz konecne dodelal writeable cursory. Jsem ochoten to zasponzorovat pokud to nepujde do desitek tisic ceskych inflacnich jednotek.

Kdyby se nekdo nudil tak by mohl v ramci vyuky udelat balik Oracle kompatibilnich funkci...

Mate nejaky seznam tech Oracle nejpotrebnejsich funkci?

na jaky email to mam poslat? A je nutne pro uspesne vyrizeni prikladat i takove ty obrazky? Ja jsem jich vetsinu namastil v pgsql, ale bylo by dobre je mit v C.

Treba na ten mail co je pod tim clankem :-) Netvrdim, ze to na 100% napisu, ale zajima mne to.

Ja mam zkusenost, ze pokud nasadite nejakou verzi do produkce, prakticky receno 7.4.1, tak uzivatele nedokopete k upgradu na zadne vyssi 7.4 verze pokud jim to nezacne padat. Coz se mne jeste nestalo.

Produkcni zasada zni: pokud databaze jede - nestourat do toho.

Mimochodem root by mel prejit na jiny DB backend, dost casto to hazi chyby nemuzu komunikovat s databazi. Misto hrani si s barvickama, bych resil nejprve toto. Kdyby to same delal muj produkcni server, zakaznici by uz dost prskali. Tak tady zase prskam ja :)

Kdyz to tak procitam ... tablespaces, savepoints, point-in-time recovery ... silne mi to pripomina mladsiho bratricka Oraclu. Sice o hodne mladsiho a oproti starsimu ponekud mene schopneho, ale vsechna cest vyvojarum. PostgreSQL rozhodne patri mezi plnohodnotne relacni databaze a ma vlastnosti, o kterych si vyvojari MySQL muzou leda nechat zdat.

Nemyslim, ze historicky je PostgreSQL ohodne mladsim nez Oracle:

http://www.root.cz/clanek/892

Nainstaloval jsem si postgreSQL 8 pod windows 2000 vcetne pgAdmina 3. Pri instalaci me to neslo neinstalovat jako service, tak sem dal instalaci bez service.

Jak se mam ted dostat pres pgAdmina do databaze? Jaky je username, initial DB a heslo? Nikde na netu to neni...

dik

initial DB je template1, std username postgres. Pri instalaci urcujete jednak passwd a user pro service, jednak passwd a user pro superusera. V nastaveni service je sice hlaska, ze pokud necham prazdne heslo, vygeneruje je to, nicmene, pokud jsem jej nevyplnil, nedostal jsem se dal. Pokud jsem hesla specifikoval, vsechno jelo bez problemu.

Zdravim, PostgreSQL se zabyvam uz od verze 5.x - to se jeste jmenovalo trochu jinak a nemohu se zbavit dojmu, ze verze 8.0. je, jak to rici kulantne, kvalitativne vyrazne podprumerna oproti ostatnim prelomovym verzim... (7.0 i 6.0).
O vikendu jsem mel moznost vyzkouset a dukladne proklepnout Win32 port (Na WinXP Prof SP1 + updates)... - teda to byl porod. Nevim, ktereho kretena napadlo, ze PGDATA bude v \Program files\Postgresql 8.0\data... bez moznosti si vybrat jinou lokaci. Dalsi zasadni problem je, ze initdb se odmitne zinicializovat na svazku, ktery nema NTFS... takze pokud mate Program files na FAT32 z duvodu rychlosti a NTFS svazek jinde, musite si pomoci rucne - polozka Browse je v instalatoru Disabnuta... (o tom vsem se ale dozvite, az to pri instalaci sleti na drzku)

Dalsi vec je striktni odmitnuti behu pod uzivatelem, ktery ma jakekoli administratorska prava... - na velkem serveru bych to mozna pochopil, na domaci stanici nikoli... ono nejen ze mu vadi Domain admin (budiz), on mu dokonce vadi i Local Admin (kdo doma se zbavuje moznosti instalovat programy a tedy se rucne vykopava z Lokal adminu, kde je defaultne?)

Chapu, ze v Linuxu na to jdeme pres balickovaci system (co jineho je MS Installer?!), takze pozadavky jsou +- stejne, stejne by mohly a mely byt i moznosti.

Jak uz bylo zmineno, pro verzi 8.0 se jiz vice jak 5 let slibovaly replikace. Kazda trosku slusnejsi databaze jiz replikace ma buil-in a na par kliknuti/prikazu je rozchodi (vcetne opovrhovane MySQL, kde diky zretezeni A->B->C->A muze to fungovat i multi-master)... PostgreSQL NIC a to tak, ze vubec NIC... - mame pytel polomrtvych projektu master-slave ci master-multislave (psany od Javy pres perl, TCL apod.), master-master neni v podstate nic. Slony, ktere existuje pouze ve verzi I je master-multislave. Vzhledem k tomu, ze zrovna touto otazkou jsem se jako druhou poradi zabyval cely vikend a prolezl jsem vsechno mozne, vim moc dobre, ze existuje moznost na urovni SPI, triggeru ci jen datovych tabulek. Jako pouzitelne se jevi projekty erServer (Java), Slony, pripadne PgReplikator Japoncu, ktery je primarne urcen pro jine ucely, ale ve sve podstate jako jedinny by teoreticky mohl (prakticky to nikdo nepotvrdil ani v jedine spravne konferenci ohledne replikaci a PgSQL (ktera ma trafic cca 20 mailu mesicne)) fungovat style multi-master. Pak tu mame mrtve (i oficialne) projekty Postgres-R (skoncil u verze 7.2 - ackoli loni v lete mel kdosi snahu to posunout dal, vysledek jsem ani v CVS nenasel), DB(cosi), PPreplication (skoncili u verze 6, teoreticky budou fungovat i s verzi 7.X).

Plne chapu, ze replikace jsou high enterprise oblast, stejne se mi zdalo ujete za tu omezenou funcionalitu erServeru (kuk do historie) davat deset tycek dolaru rocne, bohuzel dneska je uz maji vsichni okolo - aspon master-multislave, zatimco vyvojari misto technicke debaty nad rezolutnimi algoritmy pri kolizich a replikacemi (ano, je co debatovat a rozhodovat jak se bude chovat, protoze pry asyncu to proste jinak nejde a nepujde ani dle teorii), ktere chce vice uzivatelu nez nativni (tim je mysleno to, ze to nepotrebuje viditelne Cygwin a umi to bezet jako service? - ptam se proto, ze Cygwin je vevnitr furt, jen to neni videt, aspon kompilator (= i knihovny) a jako service to snad umime udelat i bez nativniho portu) Win32 port... - nasel jsem nekde i nejake statistiky co chybi vice, kde to sice bylo skoro vyrovnane, ale o par procent take vedly replikace....

Nemohu ci pomoci, drivejsi main release znamenaly opravdu velky posun kupredu, tato 8.0 by mela byt spise 7.5.0, protoze s vyjimkou PITRu (ktery by teoreticky mohl jit vyuzit jako podpora pro ty slibovane replikace - na bazi binarniho transakcniho LOGu funguji replikace u mnoha jinych databazi a to i asynchronne) v podstate ty zmeny nejsou zdaleka takove, jako byly ty jine major verze... uprimne, jsem docela zklaman a verim ze verze 8.1. dotahne nejake nedostatky a treba, jak bylo v konferenci spravne podotknuto se ve verzi 12 konecne dockame alespon elementarnich replikaci, ktere budeme konfigurovat trochu vhodnejsim zpusobem nez mnozstvim insertu, patchovanim hlavniho stromu, complilovanim odstepene verze ci ja nevim cim vsim to dneska musime delat abychom dostali elementarni a ne prilis spolehlivou funkcionalitu....

Zmeny v PostgreSQL jsou spis neviditelne :-). Normalni uzivatel vyuzije predevsim inteligentnejsi optimalizator a sikovnejsi pouziti indexu. Ted hodne pouzivam plperlu a moznost zachyceni vyjimky v plpgsql se mi taky dost hodi. Ale stale je co v PostgreSQL dodelavat, chybi fura veci, replikace jsou jen jednou z nich. Bohuzel pro pristi verzi je ukol cislo jedna nahrazeni ARCu, a jak sleduji konferenci, vyvojari nemaji ted chut diskutovat o necem jinem.