postgres/doc/FAQ_russian

               Otvety na chasto zadavaemye voprosy po PostgreSQL
                                       
   Data poslednego obnovleniya: Sreda 15 dekabrya 20:06:34 EST 2004
   
   Anglijskij variant soprovozhdaet: Bryus Mom'yan (Bruce Momjian)
   (pgman@candle.pha.pa.us)
   
   Perevel na russkij: Viktor Vislobokov (corochoone@perm.ru)
   
   Samuyu svezhuyu anglijskuyu versiyu dokumenta mozhno najti na
   http://www.PostgreSQL.org/docs/faqs/FAQ.html.
   
   Otvety na voprosy specifichnye dlya konkretnyh platform mozhno najti
   na http://www.PostgreSQL.org/docs/index.html.
     _________________________________________________________________
   
                              Obschie voprosy
                                      
   1.1) CHto takoe PostgreSQL? Kak proiznositsya `eto nazvanie?
   1.2) Kakovy avtorskie prava na PostgreSQL?
   1.3) Na kakih Unix platformah rabotaet PostgreSQL?
   1.4) Suschestvuyut li versii portirovannye ne na Unix sistemy?
   1.5) Gde mozhno vzyat' PostgreSQL?
   1.6) Gde poluchit' podderzhku?
   1.7) Kakaya versiya poslednyaya?
   1.8) Kakaya dokumentaciya imeetsya v nalichii?
   1.9) Kak najti informaciyu ob izvestnyh oshibkah ili otsutstvuyuschih
   vozmozhnostyah?
   1.10) Kak nauchit'sya SQL?
   1.11) Reshena li v PostgreSQL problema 2000-go goda (Y2K)?
   1.12) Kak prisoedinitsya k komande razrabotchikov?
   1.13) Kak otpravit' soobschenie ob oshibke?
   1.14) Kak sravnivat' PostgreSQL s drugimi SUBD?
   1.15) Kak okazat' finansovuyu pomosch' PostgreSQL?
   
                 Voprosy pol'zovatelej po klientskoj chasti
                                      
   2.1) Suschestvuyut li ODBC drajvera dlya PostgreSQL?
   2.2) Kakie instrumenty suschestvuyut dlya ispol'zovaniya PostgreSQL
   cherez Web?
   2.3) Est' li u PostgreSQL graficheskij interfejs pol'zovatelya?
   2.4) Kakie yazyki mogut vzaimodejstvovat' s PostgreSQL?
   
                         Voprosy administrirovaniya
                                      
   3.1) Kak mne ustanovit' PostgreSQL v mesto otlichnoe ot
   /usr/local/pgsql?
   3.2) Kogda ya zapuskayu postmaster, ya poluchayu soobschenie Bad
   System Call ili soobschenie core dumped. Pochemu?
   3.3) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
   IpcMemoryCreate. Pochemu?
   3.4) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
   IpcSemaphoreCreate. Pochemu?
   3.5) Kak mne upravlyat' soedineniyami s drugih komp'yuterov?
   3.6) Kakie nastrojki mne nuzhno sdelat' dlya uluchsheniya
   proizvoditel'nosti?
   3.7) Kakie vozmozhnosti dlya otladki est' v nalichii?
   3.8) Pochemu ya poluchayu soobschenie "Sorry, too many clients" kogda
   pytayus' podklyuchit'sya k baze?
   3.9) CHto nahoditsya v kataloge pgsql_tmp?
   3.10) Pochemu neobhodimo delat' dump i restore pri obnovlenii vypuskov
   PostgreSQL?
   3.11) Kakoe komp'yuternoe "zhelezo" ya dolzhen ispol'zovat'?
   
                           Voprosy `ekspluatacii
                                      
   4.1) V chem otlichie mezhdu binarnym i normal'nym kursorom?
   4.2) Kak vypolnit' SELECT tol'ko dlya neskol'kih pervyh strochek
   zaprosa? Dlya proizvol'noj stroki?
   4.3) Kak poluchit' spisok tablic ili drugih komponentov v psql?
   4.4) Kak udalit' kolonku iz tablicy ili izmenit' eio tip dannyh?
   4.5) Kakovy maksimal'nye razmery dlya zapisej, tablic i bazy dannyh?
   4.6) Kak mnogo diskovogo prostranstva v baze dannyh nuzhno dlya
   sohraneniya dannyh iz obychnogo tekstovogo fajla?
   4.7) Kak mne ubedit'sya, chto suschestvuyut nuzhnye mne tablicy,
   indeksy, bazy dannyh i pol'zovateli?
   4.8) U menya medlenno rabotayut zaprosy ili ne proishodit
   ispol'zovaniya indeksov. Pochemu?
   4.9) Kak posmotret' na to, kak optimizator vypolnyaet moj zapros?
   4.10) CHto takoe R-tree indeks?
   4.11) CHto takoe Genetic Query Optimizer?
   4.12) Kak mne vypolnit' poisk regulyarnogo vyrazheniya i poisk
   nezavisimyj ot registra bukv poisk regulyarnogo vyrazheniya? Kak mne
   ispol'zovat' indeks dlya poiska nezavisimogo ot registra bukv?
   4.13) Kak ya mogu opredelit', chto znachenie polya ravno NULL v
   kakom-libo zaprose?
   4.14) Kakovy otlichiya mezhdu raznymi simvol'nymi tipami?
   4.15.1) Kak mne sozdat' pole serial/s-avto-uvelicheniem?
   4.15.2) Kak mne poluchit' znachenie pri vstavke SERIAL?
   4.15.3) Ne mozhet li poluchit'sya tak, chto ispol'zovanie currval() i
   nextval() privedet k zaciklirovaniyu s drugimi pol'zovatelyami?
   4.15.4) Pochemu chisla iz moej posledovatel'nosti ne ispol'zuyutsya
   snova pri otmene tranzakcii? Pochemu sozdayutsya razryvy pri numeracii
   v kolonke, gde ya ispol'zuyu posledovatel'nost'/SERIAL?
   4.16) CHto takoe OID? CHto takoe TID?
   4.17) CHto oznachayut nekotorye terminy ispol'zuemye v PostgreSQL?
   4.18) Pochemu ya poluchayu oshibku "ERROR: Memory exhausted in
   AllocSetAlloc()"?
   4.19) Kak mne uznat', kakaya versiya PostgreSQL zapuschena?
   4.20) Pochemu pri rabote s moim bol'shim ob"ektom ya poluchayu oshibku
   "invalid large obj descriptor"?
   4.21) Kak mne sozdat' kolonku kotoraya po umolchaniyu budet soderzhat'
   tekuschee vremya?
   4.22) Pochemu moi podzaprosy, ispol'zuyuschie IN tak medlenno
   rabotaeyut?
   4.23) Kak vypolnit' vneshnee svyazyvanie?
   4.24) Kak vypolnyat' zaprosy, ispol'zuyuschie neskol'ko baz dannyh?
   4.25) Kak mne vernut' iz funkcii neskol'ko zapisej?
   4.26) Pochemu ya ne mogu nadezhno sozdavat'/udalyat' vremennye tablicy
   v funkciyah PL/PgSQL?
   4.27) Kakie opcii shifrovaniya suschestvuyut?
   
                          Rasshireniya PostgreSQL
                                      
   5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya
   zapuskayu ee v psql, pochemu ya poluchayu core dump?
   5.2) Kak ya mogu vnesti nekotorye klassnye novye tipy i funkcii v
   PostgreSQL?
   5.3) Kak mne napisat' C funkciyu, vozvraschayuschuyu zapis'?
   5.4) YA izmenil ishodnyj fajl. Pochemu posle perekompilyacii ya ne
   vizhu izmenenij?
     _________________________________________________________________
   
                              Obschie voprosy
                                      
    1.1) CHto takoe PostgreSQL? Kak proiznositsya `eto nazvanie?
    
   PostgreSQL proiznositsya Post-Gres-Q-L (Post-Gres-K'yu-`El). Po adresu
   http://www.postgresql.org/postgresql.mp3 dostupen zvukovoj fajl s
   primerom kak `eto nuzhno proiznosit'.
   
   PostgreSQL - `eto rasshirenie SUBD POSTGRES (i po`etomu inogda
   govoryat prosto "Postgres"), issledovatel'skij prototip novogo
   pokoleniya SUBD. PostgreSQL odnovremenno sohranyaet moschnuyu model'
   dannyh i obschirnoe kolichestvo tipov POSTGRES, i zameschaet yazyk
   zaprosov PostQuel na rasshirennoe podmnozhestvo SQL. PostgreSQL - `eto
   svobodnoe i polnost'yu otkrytoe programmnoe obespechenie.
   
   Razrabotku PostgreSQL vypolnyaet komanda razrabotchikov, vse
   uchastniki kotoroj podpisany na spisok rassylki razrabotchikov. V
   nastoyaschee vremya, ih koordinatorom yavlyaetsya Mark Furn'e (Marc G.
   Fournier) (scrappy@PostgreSQL.org). (Sm. sekciyu 1.6 o tom, kak
   podklyuchit'sya k razrabotke). `Eta komanda teper' otvechaet za vsyu
   razrabotku PostgreSQL. Dannyj proekt yavlyaetsya obschestvennym i ne
   upravlyaetsya kakoj-libo kompaniej. Podrobnosti smotrite v FAQ dlya
   razrabotchikov, http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html
   
   Avtorami PostgreSQL 1.01 yavlyayutsya `Endryu YU (Andrew Yu) i Dzholi
   CHen (Jolly Chen). Mnogie drugie vnesli svoj vklad v perenos na drugie
   platformy, testirovanie, otladku i rasshirenie `etogo koda.
   Pervonachal'nyj kod Postgres, iz kotorogo poyavilsya PostgreSQL, byl
   itogom usilij mnogih akademicheskih studentov, neakademicheskih
   studentov i mnozhestva raznyh programmistov, rabotavshih pod
   rukovodstvom professora Majkla Stounbrejkera (Michael Stonebraker) v
   Kalifornijskom universitete, Berkli.
   
   Pervonachal'noe imya, dannoe v Berkli, bylo Postgres. Kogda v 1995
   godu byla dobavlena funkcional'nost' SQL, `eto imya bylo izmeneno na
   Postgres95. No i `eto imya bylo izmeneno v konce 1996 na PostgreSQL.
   
    1.2) Kakovy avtorskie prava na PostgreSQL?
    
   PostgreSQL popadaet pod dejstvie sleduyuschego COPYRIGHT:
   
   Sistema Upravleniya Bazami Dannyh PostgreSQL
   
   Portions copyright (c) 1996-2004, PostgreSQL Global Development Group
   Portions Copyright (c) 1994-6 Regents of the University of California
   
   Predostavlyayutsya prava na ispol'zovanie, kopirovanie, izmenenie i
   rasprostranenie dannogo programmnogo obespecheniya i ego dokumentacii
   dlya lyubyh celej, besplatno i bez podpisaniya kakogo-libo
   soglasheniya, pri uslovii chto dlya kazhdoj kopii budut predostavleny
   dannoe vyshe zamechanie ob avtorskih pravah, tekuschij paragraf i dva
   sleduyuschih paragrafa.
   
   KALIFORNIJSKIJ UNIVERSITET NE NESET NIKAKOJ OTVETSTVENNOSTI ZA LYUBYE
   POVREZHDENIYA, VKLYUCHAYA POTERYU DOHODA, NANESENNYE PRYAMYM ILI
   NEPRYAMYM, SPECIAL'NYM ILI SLUCHAJNYM ISPOL'ZOVANIEM DANNOGO
   PROGRAMMNOGO OBESPECHENIYA ILI EGO DOKUMENTACII, DAZHE ESLI
   KALIFORNIJSKIJ UNIVERSITET BYL IZVESCHEN O VOZMOZHNOSTI TAKIH
   POVREZHDENIJ.
   
   KALIFORNIJSKIJ UNIVERSITET SPECIAL'NO OTKAZYVAZYVAETSYA PREDOSTAVLYAT'
   LYUBYE GARANTII, VKLYUCHAYA, NO NE OGRANICHIVAYAS' TOL'KO `ETIMI
   GARANTIYAMI: NEYAVNYE GARANTII PRIGODNOSTI TOVARA ILI PRIGODNOSTI DLYA
   OTDEL'NOJ CELI. DANNOE PROGRAMMNOE OBESPECHENIE PREDOSTAVLYAETSYA NA
   OSNOVE PRICIPA "KAK EST'" I KALIFORNIJSKIJ UNIVERSITET NE OBYAZAN
   PREDOSTAVLYAT' SOPROVOZHDENIE, PODDERZHKU, OBNOVLENIYA, RASSHIRENIYA
   ILI IZMENENIYA.
   
   Vysheizlozhennoe yavlyaetsya BSD licenziej, klassicheskoj licenziej
   programmnogo obespecheniya s otkrytym kodom. `Eta licenziya ne
   nakladyvaet ogranichenij na ispol'zovanie ishodnogo koda. Nam
   nravitsya `eta licenziya i my ne sobiraemsya eio menyat'.
   
    1.3) Na kakih Unix platformah rabotaet PostgreSQL?
    
   Obychno, PostgreSQL mozhet rabotat' na lyuboj sovremennoj platforme
   sovmestimoj s Unix. V instrukcii po ustanovke, vy najdete spisok teh
   platform, na kotoryh byli provedeny testovye zapuski PostgreSQL k
   momentu vyhoda dannoj versii.
   
    1.4) Suschestvuyut li versii perenesennye ne na Unix sistemy?
    
   Nachinaya s versii 8.0, PostgreSQL bez vsyakih uhischrenij rabotaet na
   operacionnyh sistemah Microsoft Windows, osnovannyh na NT, takih kak
   Win2000, WinXP i Win2003. Paket installyatora dostupen po adresu
   http://pgfoundry.org/projects/pginstaller. Versii Windows, osnovannye
   na MS-DOS (Win95, Win98, WinMe) mogut zapuskat' PostgreSQL s
   pomosch'yu Cygwin.
   
   Takzhe suschestvuet versiya sportirovannaya pod Novell Netware 6 na
   http://forge.novell.com.
   
    1.5) Gde mozhno vzyat' PostgreSQL?
    
   Naprimer, vospol'zovavshis' anonimnym dostupom na ftp sajt PostgreSQL
   ftp://ftp.PostgreSQL.org/pub. Spisok zerkal vy najdete na nashem
   osnovnom sajte.
   
    1.6) Gde poluchit' podderzhku?
    
   Osnovnoj spisok rassylki: pgsql-general@PostgreSQL.org. V nem mozhno
   obsuzhdat' lyubye temy, kasayuschiesya PostgreSQL. CHtoby
   podpisat'sya, otprav'te pis'mo po `elektronnoj pochte, v kotorom v
   tele pis'ma (ne v teme) napishite sleduyuschie stroki:
    subscribe
    end

   na adres pgsql-general-request@PostgreSQL.org.
   
   Suschestvuet dajzhest spisok. CHtoby podpisat'sya na nego, otprav'te
   pis'mo po `elektronnoj pochte na adres:
   pgsql-general-digest-request@PostgreSQL.org i v tele pis'ma napishite
   strochki strochki:
    subscribe
    end

   Dajzhesty otpravlyayutsya podpischikam, kogda v osnovnom spiske
   rassylki nakopitsya okolo 30 kilobajt soobschenij.
   
   Dostupen i spisok rassylki soobschenij ob oshibkah. CHtoby
   podpisat'sya na `etot spisok, otprav'te po `elektronnoj pochte pis'mo
   na adres pgsql-bugs-request@PostgreSQL.org i v tele pis'ma napishite
   strochki strochki:
    subscribe
    end

   Takzhe imeetsya spisok rassylki s diskussiyami razrabotchikov. CHtoby
   podpisat'sya na `etot spisok, otprav'te po `elektronnoj pochte pis'mo
   na adres pgsql-hackers-request@PostgreSQL.org i v tele pis'ma
   napishite strochki strochki:
    subscribe
    end

   Dopolnitel'nye spiski rassylki i infomaciyu o PostgreSQL mozhno najti
   na domashnej stranichke PostgreSQL po adresu:
   
     http://www.PostgreSQL.org
     
   Glavnym IRC kanalom yavlyaetsya #postgreql, raspolozhennyj na servere
   Freenode (irc.freenode.net). CHtoby podklyuchit'sya, vy mozhete
   ispol'zovat' komandu Unix irc -c '#postgresql' "$USER"
   irc.freenode.net ili lyuboj drugoj IRC klient. Na `etom zhe servere
   suschestvuyut kanaly na ispanskom (#postgresql-es) i francuzskom
   (#postgresqlfr) yazykah. Takzhe suschestvuet kanal po PostgreSQL na
   servere EFNet.
   
   Spisok kommercheskoj podderzhki kompanij dostupen na
   http://techdocs.postgresql.org/companies.php.
   
    1.7) Kakaya poslednyaya versiya?
    
   Poslednij vypusk PostgreSQL - `eto versiya 7.4.6
   
   My planiruem vypuskat' novye versii kazhdye 6-8 mesyacev.
   
    1.8) Kakaya dokumentaciya imeetsya v nalichii?
    
   V distributiv vklyuchayutsya razlichnye rukovodstva, stranicy
   `elektronnogo rukovodstva man i nekotorye malen'kie testovye primery.
   Smotrite v katalog /doc. Vy takzhe mozhete prosmatrivat' dokumentaciyu
   v Internet po adresu http://www.PostgreSQL.org/docs.
   
   Suschestvuet dve knigi po PostgreSQL dostupnye po adresam
   http://www.PostgreSQL.org/docs/awbook.html i
   http://www.commandprompt.com/ppbook/. Spisok knig po PostgreSQL,
   kotorye mozhno kupit' dostupen po adresu
   http://techdocs.postgresql.org/techdocs/bookreviews.php. Krome togo,
   po adresu http://techdocs.PostgreSQL.org/ vy mozhete najti kollekciyu
   tehnicheskih statej posvyaschennyh PostgreSQL.
   
   psql imeet neskol'ko prekrasnyh komand \d dlya otobrazheniya
   informacii po tipam, operatoram, funkciyam, agregatam i t.d.
   
   Nash sajt soderzhit esche bol'she informacii.
   
    1.9) Kak najti informaciyu ob izvestnyh oshibkah ili otsutstvuyuschih
    vozmozhnostyah?
    
   PostgreSQL podderzhivaet rasshirennyj podklass SQL-92. Smotrite nash
   spisok TODO na predmet izvestnyh oshibok, otsutstvuyuschih
   vozmozhnostej i buduschih planov.
   
    1.10) Kak mne nauchit'sya SQL?
    
   Kniga po PostgreSQL na http://www.PostgreSQL.org/docs/awbook.html
   nauchit SQL. Suschestvuet drugaya kniga po PostgreSQL na
   http://www.commandprompt.com/ppbook. Est' prekrasnyj uchebnik na
   http://www.intermedia.net/support/sql/sqltut.shtm, na
   http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM,
   i na http://sqlcourse.com.
   
   Esche odin uchebnik - `eto kniga "Teach Yourself SQL in 21 Days,
   Second Edition" (Osvoj samostoyatel'no SQL za 21 den', Vtoraya
   redakciya) na http://members.tripod.com/er4ebus/sql/index.htm
   
   Mnogim iz nashih pol'zovatelej nravitsya kniga The Practical SQL
   Handbook, Bowman, Judith S., et al., Addison-Wesley. Drugim nravitsya
   The Complete Reference SQL, Groff et al., McGraw-Hill.
   
    1.11) Reshena li v PostgreSQL problema 2000-go goda (Y2K)?
    
   Da, my legko rabotaem s datami posle 2000 goda i pered 2000 godom.
   
    1.12) Kak prisoedinitsya k komande razrabotchikov?
    
   Dlya nachala, skachajte poslednyuyu versiyu ishodnyh tekstov i
   prochtite dokumentaciyu razrabotchikov PostgreSQL na nashem sajte ili
   v distributive. Zatem, podpishites' na spiski rassylki pgsql-hackers i
   pgsql-patches. Dalee, otpravlyajte ispravleniya (patches) vysokogo
   kachestva v spisok pgsql-patches.
   
   Suschestvuet ogranichennyj spisok lyudej, kotoryj imeyut privelegiyu
   vnosit' izmeneniya v CVS arhiv PostgreSQL. Kazhdyj iz `etih lyudej v
   svoe vremya otpravil tak mnogo vysokokachestvennyh ispravlenij, chto
   ih bylo nevozmozhno ostavit' bez vnimaniya i oni byli udostoeny
   previlegii vnosit' izmeneniya, i my uvereny, chto te ispravleniya,
   kotorye oni vnesut budut vysokogo kachestva.
   
    1.13) Kak otpravit' soobschenie ob oshibke??
    
   Zapolnite formu ob oshibke v PostgreSQL, kotoraya raspolozhena na
   http://www.postgresql.org/bugform.html.
   
   Takzhe ne zabud'te posmotret' na ftp://ftp.PostgreSQL.org/pub na
   predmet bolee svezhih versij PostgreSQL ili zaplat.
   
    1.14) Kak sravnivat' PostgreSQL s drugimi SUBD?
    
   Suschestvuet neskol'ko metodov sravneniya programmnogo obespecheniya:
   vozmozhnosti, proizvoditel'nost', nadezhnost', podderzhka i cena.
   
   Vozmozhnosti
          PostgreSQL imeet bol'shinstvo vozmozhnostej predstavlennyh v
          bol'shih kommercheskih SUBD, takie kak: tranzakcii, podzaprosy,
          triggery, predstavleniya, ssylochnoj celostnosti vtorichnogo
          klyucha i raznye blokirovki. U nas est' nekotorye vozmozhnosti,
          kotoryh net u nih: tipy, opredelyaemye pol'zovatelem, mehanizm
          nasledovaniya, pravila i konkuretnoe mnogoversionnoe upravlenie
          dlya raboty s soderzhimym blokirovok.
          
   Proizvoditel'nost'
          PostgreSQL imeet proizvoditel'nost' shodnuyu s drugimi
          kommercheskimi SUBD i s SUBD s otkrytym ishodnym kodom, v
          kakih-to aspektah rabotaya bystree chem oni, v kakih-to
          medlenee. V sravnenii s MySQL ili obydennee SUBD, my bystree,
          kogda pol'zovatelej mnogo, a takzhe na kompleksnyh zaprosah i
          chtenii/zapisi zagruzki zaprosa. MySQL bystree dlya prostyh
          SELECT zaprosov, vypolnyaemyh nebol'shim kolichestvom
          pol'zovatelej. I razumeetsya, MySQL ne imeet kakih-libo
          vozmozhnostej iz perechislenyh vyshe, v sekcii Vozmozhnosti. My
          delaem upor na nadezhnost' i rasshirennye vozmozhnosti, no my
          takzhe prodolzhaem uvelichivat' proizvoditel'nost' s kazhdym
          vypuskom. Suschestvuet interesnaya stranichka v Internet,
          sravnivayuschaya PostgreSQL i MySQL na
          http://openacs.org/philosophy/why-not-mysql.html. Takzhe, MySQL
          - `eto kompaniya, kotoraya rasprostranyaet svoj produkt cherez
          otkrytye ishodnye teksty i trebuet kommercheskuyu licenziyu na
          zakrytoe programmnoe obespechenie, a ne soobschestvo
          razrabotchikov s otkrytymi ishodnymi tekstami, kak PostgreSQL.
          
   Nadezhnost'
          My ponimali, chto nasha SUBD dolzhna byt' nadezhnoj ili ona
          nichego ne budet stoit'. My staraemsya vypuskat' horosho
          proverennyj, stabil'nyj kod, kotoryj soderzhit minimum oshibok.
          Kazhdyj vypusk prohodit stadiyu beta-testirovaniya po krajnej
          mere v techenii odnogo mesyaca i nasha istoriya vypuskov
          pokazyvaet chto my mozhem predostavlyat' stabil'nye, monolitnye
          vypuski, kotorye gotovy k produktivnomu ispol'zovaniyu. My
          verim, chto my proizvodim proverku ne huzhe, chem u drugih
          SUBD.
          
   Podderzhka
          Nash spisok rassylki predostavlyaet vozmozhmozhnost' obscheniya
          s bol'shoj gruppoj razrabotchikov i pol'zovatelej, kotorye
          mogut pomoch' reshit' lyubye voznikshie problemy. V to zhe
          vremya, my ne garantiruem kakie-libo ispravleniya, no i
          razrabotchiki kommercheskih SUBD ne vsegda delayut
          ispravleniya. Pryamoj dostup k razrabotchikam, soobschestvu
          pol'zovatelej, rukovodstvam i ishodnym tekstam chasto delayut
          podderzhku PostgreSQL prevoshodyaschej drugie SUBD.
          Suschestvuet kommercheskaya podderzhka po rezul'tam voznikshih
          incidentov, kotoraya dostupna dlya teh komu ona nuzhna.
          (Smotrite Sekciyu 1.6.)
          
   Cena
          Nash produkt besplaten kak dlya kommercheskogo tak, i ne dlya
          kommercheskogo ispol'zovaniya. Vy mozhete dobavlyat' svoj kod v
          nash produkt bez ogranichenij, za isklyucheniem teh, chto
          opisyvayutsya v nashej licenzii stilya BSD, kotoraya privedena
          vyshe.
          
    1.15) Kak okazat' finansovuyu pomosch' PostgreSQL?
    
   PostgreSQL imeet odnorangovuyu infrastrukturu s togo samogo vremeni
   kak my nachali razrabotku v 1996 godu. My dolzhny blagodarit' za `eto
   Marka Furn'e (Marc Fournier), kotoryj sozdal `etu infrastrukturu i
   upravlyaet ej na protyazhenii `etih let.
   
   Kachestvennaya infrastruktura ochen' vazhna dlya proektov s otkrytym
   ishodnym kodom. Ona predotvraschaet raskoly, kotorye mogut sil'no
   zaderzhat' postupatel'noe dvizhenie proekta.
   
   Razumeetsya, `eta infrastruktura ne yavlyaetsya deshevoj. Suschestvuet
   nekotoroe kolichestvo ezhemesyachnyh i odnorazovyh rashodov, kotorye
   trebuyut deneg. Esli vy ili vasha kompaniya imeet den'gi, kotorye
   mozhno peredat' v pomosch' nashim usiliyam, pozhalujsta posetite
   stranichku https://store.pgsql.com/shopping/ i sdelajte svoj vklad.
   
   Hotya na stranichke govoritsya o PostgreSQL, Inc, punkt
   "contributions" prednaznachen isklyuchitel'no dlya podderzhki proekta
   PostgreSQL i ne peredaetsya kakoj-libo konkretnoj kompanii. Esli
   hotite, to mozhete `eto proverit', napisav pis'mo na kontaktnyj adres.
     _________________________________________________________________
   
   Esli u vas est' istorii po uspeshnomu primeneniyu PostgreSQL,
   pozhalujsta, prisylajte ih na nash sajt propagandy
   http://advocacy.postgresql.org.
   
                 Voprosy pol'zovatelej po klientskoj chasti
                                      
    2.1) Suschestvuyut li ODBC drajvera dlya PostgreSQL?
    
   Suschestvuet dva ODBC drajvera, PsqlODBC i OpenLink ODBC.
   
   Vy mozhete skachat' PsqlODBC s
   http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.
   
   OpenLink ODBC mozhno vzyat' na http://www.openlinksw.com. `Etot
   drajver rabotaet s ih standartnym klientskim programmnym
   obespecheniem, ispol'zuyuschim ODBC, i takim obrazom, ODBC drajvery
   dlya PostgreSQL dostupny dlya kazhdoj iz podderzhivaemyh imi platform
   (Win, Mac, Unix, VMS).
   
   Vozmozhno oni budut prodavat' svoj produkt tem komu nuzhna
   kommercheskaya podderzhka, no besplatnaya versiya vsegda budet
   dostupna. Pozhalujsta, napravlyajte voprosy na adres
   postgres95@openlink.co.uk.
   
    2.2) Kakie instrumenty suschestvuyut dlya ispol'zovaniya PostgreSQL cherez
    Web?
    
   Prekrasnoe vvedenie vo vzaimodejstvie baz dannyh i Web mozhno najti
   na: http://www.webreview.com
   
   Dlya integracii s Web, odnim iz prevoshodnyh instrumentov yavlyaetsya
   PHP. Domashnyaya stanichka http://www.php.net.
   
   Dlya kompleksnyh reshenij, mnogie pol'zuyutsya Perl interfejsom i
   CGI.pm ili mod_perl.
   
    2.3) Est' li u PostgreSQL graficheskij interfejs pol'zovatelya?
    
   Da, suschestvuet neskol'ko graficheskih interfejsov dlya PostgreSQL.
   `Eto PgAccess (http://www.pgaccess.org), PgAdmin III
   (http://www.pgadmin.org), RHDB Admin
   (http://sources.redhat.com/rhdb/), TORA (http://www.globecom.net/tora/
   (chastichno kommercheskoe PO) i Rekall (
   http://www.thekompany.com/products/rekall/, kommercheskij). Takzhe
   est' PhpPgAdmin ( http://phppgadmin.sourceforge.net/) - interfejs k
   PostgreSQL, osnovannyj na Web.
   
    2.4) Kakie yazyki mogut vzaimodejstvovat' s PostgreSQL?
    
   Kakie-libo interfejsy dlya PostgreSQL suschestvuyut dlya bol'shinstva
   populyarnyh yazykov programmirovaniya. Posmotrite spisok modulej
   rasshireniya dlya teh yazykov programmirovaniya, kotorymi vy
   pol'zuetes'.
   
   Sleduyuschie interfejsy vklyuchayutsya v distributiv PostgreSQL:
     * C (libpq)
     * Embedded C (ecpg)
     * Java (jdbc)
     * Python (PyGreSQL)
     * TCL (libpgtcl)
       
   Dopolnitel'nye interfejsy dostupny po adresu
   http://gborg.PostgreSQL.org v sekcii Drivers/Interfaces.
     _________________________________________________________________
   
                         Voprosy administrirovaniya
                                      
    3.1) Kak mne ustanovit' PostgreSQL v mesto otlichnoe ot /usr/local/pgsql?
    
   Zadajte opciyu --prefix kogda zapuskaete configure.
   
    3.2) Kogda ya zapuskayu postmaster, ya poluchayu soobschenie Bad System
    Call ili soobschenie core dumped. Pochemu?
    
   `Eto mozhet byt' vyzvano raznymi problemami, no pervoe, chto nuzhno
   sdelat' - `eto ubedit'sya v tom, chto v vashem yadre ustanovleno
   rasshirenie System V. PostgreSQL trebuet, chtoby yadro podderzhivalo
   razdelyaemuyu pamyat' i semafory.
   
    3.3) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
    IpcMemoryCreate. Pochemu?
    
   Libo u vas v yadre nepravil'nye nastrojki razdelyaemoj pamyati, libo
   vashemu yadru nuzhno bol'shee kolichestvo dostupnoj razdelyaemoj
   pamyati. Te konkretnye dejstviya, kotorye vam nuzhno proizvesti
   zavisyat ot arhitektury vashej mashiny i ot togo kak mnogo buferov i
   backend processov vy nastroili dlya postmaster. Dlya bol'shinstva
   sistem, s kolichestvom buferov i processov po umolchaniyu, neobhodimyj
   minimum - `eto okolo 1 megabajta. Podrobnosti o razdelyaemoj pamyati i
   semaforah smotrite v Rukovodstve administratora PostgreSQL..
   
    3.4) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
    IpcSemaphoreCreate. Pochemu?
    
   Esli `eto soobschenie IpcSemaphoreCreate: semget failed (No space left
   on device) to nastrojki vashego yadra takovy, chto emu ne hvataet
   semaforov. Postgres trebuet odin semafor na potencial'nyj backend
   process. Vremennym resheniem yavlyaetsya zapusk postmaster s
   nastrojkami na mesh'shee kolichestvo backend processov. Ispol'zujte -N
   s znacheniem men'shim chem 32, kotoroe prinyato po umolchaniyu. Bolee
   pravil'noe reshenie - `eto uvelichit' znacheniya SEMMNS i SEMMNI v
   nastrjkah yadra.
   
   Neispravnye semafory takzhe mogut privesti k padeniyu SUBD vo vremya
   dostupa k baze dannyh.
   
   Esli vy poluchili kakoe-libo drugoe soobschenie ob oshibke, to vpolne
   vozmozhno, chto v vashem yadre voobsche ne nastroena podderzhka
   semaforov. Smotrite podrobnosti o razdelyaemoj pamyati i semaforah v
   Rukovodstve Administratora PostgreSQL.
   
    3.5) Kak mne upravlyat' soedineniyami s drugih komp'yuterov?
    
   Po umolchaniyu, PostgreSQL razreshaet tol'ko soedineniya na lokal'noj
   mashine cherez sokety domena Unix ili TCP/IP soedineniya. Drugie
   mashiny ne smogut podklyuchit'sya k baze poka vy ne izmenite
   listen_addresses v postgresql.conf i poka ne budet razreshena
   host-avtorizaciya v fajle $PGDATA/pg_hba.conf.
   
    3.6) Kakie nastrojki mne nuzhno sdelat' dlya uluchsheniya
    proizvoditel'nosti?
    
   Nesomnenno, indeksy mogut uvelichit' skorost' vypolneniya zaprosov.
   Komanda EXPLAIN ANALYZE pozvolyaet vam posmotret' kak PostgreSQL
   interpretiruet vash zapros i kakie indeksy ispol'zuyutsya.
   
   Esli vy vypolnyaete mnogo operatorov INSERT, rassmotrite vozmozhnost'
   vypolnyat' ih v bol'shoj pachke, ispol'zuya komandu COPY. `Eto
   znachitel'no bystree, chem otdel'nye INSERT. Vo-vtoryh, operatory vne
   bloka tranzakcii BEGIN WORK/COMMIT sami vypolnyayut tranzakciyu.
   Podumajte nad vypolneniem neskol'kih operatorov v odnom bloke
   tranzakcii. `Eto umen'shit kolichestvo tranzakcij. Takzhe, zadumajtes'
   nad udaleniem i peresozdaniem indeksov, kogda vy vypolnyaete bol'shie
   izmeneniya dannyh.
   
   Suschestvuet neskol'ko opcij nastrojki v Rukovodstve Administratora
   PostgreSQL. Vy mozhete zapretit' fsync() pri starte postmaster s
   opciej -o -F. `Eto predotvratit vyzovy fsync(), kotorye privodyat k
   sbrosu dannyh na disk posle kazhdoj tranzakcii.
   
   Vy mozhete takzhe ispol'zovat' opciyu shared_buffers -B dlya
   uvelicheniya kolichestva buferov razdelyaemoj pamyati, kotoraya
   ispol'zuetsya backend processami. Esli vy sdelaete znachenie `etogo
   parametra slishkom bol'shim, to postmaster mozhet ne zapustitsya
   potomu chto vy ischerpaete ogranichenie yadra na ob"em razdelyaemoj
   pamyati. Kazhdyj bufer imeet razmer v 8 kilobajt i po umolchaniyu
   vydelyaetsya 1000 buferov.
   
   Vy mozhete takzhe ispol'zovat' backend opcii sort_mem i work_mem dlya
   uvelicheniya maksimal'nogo kolichestva pamyati, kotoroe ispol'zuetsya
   backend processom dlya vremennyh sortirovok. Znachenie po umolchaniyu
   sostavlyaet 1024 (t.e. 1MB).
   
   Vy takzhe mozhete ispol'zovat' komandu CLUSTER dlya gruppirovki dannyh
   v tablicah na sovpadayuschij indeks. Podrobnosti smotrite na stranice
   rukovodstva po komande CLUSTER.
   
    3.7) Kakie vozmozhnosti dlya otladki est' v nalichii?
    
   PostgreSQL imeet neskol'ko vozmozhnostej, pozvolyayuschie poluchit'
   informaciyu o sostoyanii, kotoraya mozhet byt' ispol'zovana v
   otladochnyh celyah.
   
   Vo-pervyh, pri zapuske configure s opciej --enable-cassert, mnogie
   vyzovy assert() pozvolyayut otslezhivat' rabotu backend processa i
   ostanovku programmy pri vozniknovenii kakih-libo neozhidannostej.
   
   I postmaster, i postgres imeyut neskol'ko otladochnyh opcij.
   Vo-pervyh, pri zapuske postmaster, ubedites', chto standartnyj vyvod i
   vyvod oshibok osuschestvlyayutsya v fajl zhurnala:
    cd /usr/local/pgsql
    ./bin/postmaster >server.log 2>&1 &

   `Eto privedet k poyavleniyu fajla server.log v glavnom kataloge
   PostgreSQL. `Etot fajl soderzhit poleznuyu informaciyu o problemah ili
   oshibkah, voznikshih na servere. Postmaster imeet opciyu -d, kotoraya
   pozvolyaet poluchat' pri protokolirovanii bolee detal'nuyu infrmaciyu.
   Dlya opcii -d ukazyvaetsya chislo, kotoroe zadaet uroven' otladki.
   Bud'te ostorozhny, tak kak vysokij uroven' otladki privodit k
   generacii fajlov zhurnala bol'shogo razmera.
   
   Esli postmaster ne zapuschen, vy mozhete zapustit' postgres backend iz
   komandnoj stroki i vvesti vash operator SQL napryamuyu. `Eto
   rekomenduetsya tol'ko dlya celej otladki. Zametim, chto v `etom
   rezhime, zapros zavershaetsya simvolom novoj stroki, a ne tochkoj s
   zapyatoj. Esli vy proizvodili kompilyaciyu s otladochnymi simvoloami,
   vy mozhete ispol'zovat' lyuboj otladchik, chtoby posmotret', chto
   sluchilos'. Poskol'ku backend zapuskaetsya ne iz postmaster, on ne
   zapuskaetsya v identichnom okruzhenii i znachit problemy iteracij
   blokirovok/backend ne mogut byt' vosproizvedeny.
   
   Esli postmaster zapuschen, zapustite psql v odnom okne, zatem najdite
   PID processa postgres, ispol'zuemyj psql, ispol'zuya
        SELECT pg_backend_pid()


   Ispol'zujte otdadchik dlya podklyucheniya k postgres PID. Vy mozhete
   ustanovit' tochki preryvaniya v otladchike i zapustit' zapros iz psql.
   Esli vy proizvodite otladku zapuska postgres, vy mozhete ustanovit'
   PGOPTIONS="-W n", i zatem zapustit' psql. `Eta opciya privodit k
   zaderzhke processa zapuska na n sekund, v techenie kotoryh vy mozhete
   podklyuchit' k processu otladchik, ustanovit' lyubye tochki
   preryvaniya i prodolzhit' zapusk.
   
   Programma postgres imeet opcii -s, -A, i -t kotorye mogut byt' ochen'
   poleznymi dlya otladki i izmereniya proizvoditel'nosti.
   
   Vy takzhe mozhete skompilirovat' PostgreSQL s profilirovaniem dlya
   togo, chtoby uvidet' kakie funkcii skol'ko vremeni vypolnyayutsya.
   Fajly profilirovaniya backend'a nahodyatsya v kataloge
   pgsql/data/base/dbname. Fajl profilirovaniya klienta budet pomeschen v
   tekuschij katalog klienta. V Linux dlya vypolneniya profilirovaniya
   trebuetsya kompilyacii s -DLINUX_PROFILE.
   
    3.8) Pochemu ya poluchayu soobschenie "Sorry, too many clients" kogda
    pytayus' podklyuchit'sya k baze?
    
   Vam nuzhno uvelichit' ogranichenie na kolichestvo konkuretnyh backend
   processov pri zapuske postmaster.
   
   Po umolchaniyu ustanovlen limit na 32 processa. Vy mozhete uvelichit'
   `etot limit perezapustiv postmaster s nuzhnym znacheniem processov,
   kotoroe ukazyvaetsya v opcii -N ili izmeniv fajl postgresql.conf.
   
   Zametim, chto esli vy zadadite v opcii -N znachenie bol'she 32, to vy
   takzhe dolzhny uvelichit' znachenie v opcii -B kotoroe po umolchaniyu
   ustanovleno v 64; Znachenie opcii -B dolzhno byt' po krajnej mere
   vdvoe bol'she znacheniya opcii -N, i vozmozhno eschio bol'she dlya
   luchshej proizvoditel'nosti. Dlya bol'shego kolichestva backend
   processov, vam takzhe neploho bylo by uvelichit' nekotorye parametry
   yadra Unix. `Eto takie parametry, kak maksimal'noe kolichestvo blokov
   razdelyaemoj pamyati, SHMMAX; maksimal'noe kolichestvo semaforov,
   SEMMNS i SEMMNI; maksimal'noe kolichestvo processov, NPROC;
   maksimal'noe kolichestvo processov na pol'zovatelya, MAXUPRC; i
   maksimal'noe kolichestvo otkrytyh fajlov, NFILE i NINODE. Prichina
   sozdaniya ogranicheniya na kolichestvo backend processov kak raz i
   sostoit v tom, chtoby vashej sisteme hvatilo resursov.
   
    3.9) CHto nahoditsya v kataloge pgsql_tmp?
    
   Dannyj katalog soderzhit vremennye fajly, generiruemye obrabotchikom
   zaprosa. Naprimer, esli dlya vypolneniya ORDER BY nuzhna sortirovka i
   `eta sortirovka trebuet pamyati bol'she, chem dopuskaet parametr -S u
   backend'a, to dlya hraneniya dopolnitel'nyh dannyh sozdayutsya
   vremennye fajly.
   
   `Eti vremennye fajly dolzhny udalyat'sya avtomaticheski, no `etogo
   mozhet ne proizojti, esli backend ruhnul vo vremya sortirovki. Ostanov
   i zapusk servernogo processa obespechit ih udalenie iz kataloga.
   
    3.10) Pochemu neobhodimo delat' dump i restore pri obnovlenii vypuskov
    PostgreSQL?
    
   Razrabotchiki PostgreSQL delayut tol'ko nebol'shie izmeneniya mezhdu
   podvypuskami. Takim obrazom obnovlenie s versii 7.2 do 7.2.1 ne
   trebuet vypolneniya dump i restore. Odnako pri vyhode ocherednogo
   vypuska (t.e. pri obnovlenii naprimer, s 7.2 na 7.3) chasto menyaetsya
   vnutrennij format sistemnyh tablic i fajlov dannyh. `Eti izmeneniya
   chasto nosyat kompleksnyj harakter, tak chto net vozmozhnosti
   obespechit' obratnuyu sovmestimost' fajlov dannyh. Vypolenie dump
   pozvolyaet poluchit' dannye v obschem formate, kotoryj zatem mozhet
   byt' zagruzhen pri ispol'zovanii novogo vnutrennego formata.
   
   V teh vypuskah, gde format dannyh na diske ne menyaetsya, dlya
   provedeniya obnovleniya mozhet byt' ispol'zovan scenarij pg_upgrade
   bez ispol'zovaniya dump/restore. Kommentarii k vypusku govorit kogda
   mozhno ispol'zovat' pg_upgrade dlya `etogo vypuska.
   
    3.11) Kakoe komp'yuternoe "zhelezo" ya dolzhen ispol'zovat'?
    
   Poskol'ku "zhelezo" personal'nyh komp'yuterov yavlyaetsya naibolee
   sovmestimym, lyudi sklonny verit', chto takoe "zhelezo" imeet
   odinakovoe kachestvo. `Eto ne tak. Pamyat' ECC, SCSI i kachestvennye
   materinskie platy yavlyayutsya bolee nadiozhnymi i imeyut bolee
   luchshuyu proizvoditel'nost', chem menee dorogoe "zhelezo". PostgreSQL
   budet rabotat' na lyubom "zheleze", no esli dlya vas vazhny
   nadiozhnost' i proizvoditel'nost', to s vashej storony budet mudro
   postavit' sootvetstvuyuschee "zhelezo". Obsudit' raznoe "zhelezo"
   mozhno v nashih spiskah rassylki.
     _________________________________________________________________
   
                           Voprosy `ekspluatacii
                                      
    4.1) V chem otlichie mezhdu binarnym i normal'nym kursorom?
    
   Smotrite opisanie na stranicah rukovodstva posvyaschennym DECLARE.
   
    4.2) Kak vypolnit' SELECT tol'ko dlya neskol'kih pervyh strochek zaprosa?
    Proizvol'noj stroki?
    
   Smotrite stanicu rukovodstva posvyaschennuyu FETCH ili ispol'zujte
   SELECT ... LIMIT....
   
   Dazhe esli vy hotite poluchit' tol'ko pervye neskol'ko zapisej, budet
   vypolnen ves' zapros. Rassmotrim zapros, kotoryj imeet ORDER BY. Esli
   est' kakoj-libo indeks, kotoryj sovpadaet s ORDER BY, PostgreSQL
   mozhet vydat' tol'ko neskol'ko pervyh zaproshennyh zapisej ili mozhet
   vypolnyat' zapros poka ne budut vydany zhelaemye zapisi.
   
   To SELECT a random row, use:
    SELECT col
    FROM tab
    ORDER BY random()
    LIMIT 1;

    4.3) Kak poluchit' spisok tablic ili drugih komponentov v psql?
    
   CHtoby prosmatrivat' tablicy v psql, ispol'zujte komandu \dt. Polnyj
   spisok komand v psql vy mozhete poluchit', ispol'zuya \?. Krome togo,
   vy mozhete posmotret' ishodnyj kod psql v fajle
   pgsql/src/bin/psql/describe.c. On soderzhit komandy SQL kotorye
   generiruyutsya pri vvode v psql komand, nachinayuschihsya s obratnoj
   kosoj cherty. Vy takzhe mozhete zapustit' psql s opciej -E tak, chtoby
   `eta programma vydavala zaprosy, kotorye ona ispol'zuet dlya
   vypolneniya zadannyh vami komand. PostgreSQL takzhe predostavlyaet
   SQLi sovmestimyj s INFORMATION SCHEMA interfejs, s pomosch'yu
   kotorogo, vy mozhete sformirovat' zapros na poluchenie informacii o
   baze dannyh.
   
    4.4) Kak udalit' kolonku iz tablicy ili izmenit' eio tip dannyh?
    
   DROP COLUMN funkcional'nost' byla dobavlena v vypusk 7.3 s operatorom
   ALTER TABLE DROP COLUMN. V rannih versiyah, mozhno sdelat' tak:
    BEGIN;
    LOCK TABLE old_table;
    SELECT ...  -- vyborka vseh kolonok za isklyucheniem toj, kotoruyu hotite u
dalit'
    INTO TABLE new_table
    FROM old_table;
    DROP TABLE old_table;
    ALTER TABLE new_table RENAME TO old_table;
    COMMIT;

   Dlya izmeneniya tipa dannyh kolonki, sdelajte tak:
    BEGIN;
    ALTER TABLE tab ADD COLUMN new_col new_data_type;
    UPDATE tab SET new_col = CAST(old_col AS new_data_type);
    ALTER TABLE tab DROP COLUMN old_col;
    COMMIT;

    4.5) Kakovy maksimal'nye razmery dlya zapisej, tablic i bazy dannyh?
    
   Suschestvuyut sleduyuschie ogranicheniya:
    Maksimal'nyj razmer bazy?                    neogranichen (suschestvuyut ba
zy na 32 TB)
    Maksimal'nyj razmer tablicy?                 32 TB
    Maksimal'nyj razmer zapisi?                  1.6 TB
    Maksimal'nyj razmer polya?                    1 GB
    Maksimal'noe kolichestvo zapisej v tablice?   neogranicheno
    Maksimal'noe kolichestvo kolonok v tablice?   250-1600 v zavisimosti ot tip
a
    Maksimal'noe kolichestvo indeksov v tablice?  neogranicheno

   Razumeetsya, ponyatie "neogranicheno" na samom dele ogranichivaetsya
   dostupnym diskovym prostranistvom i razmerami pamyati/svoppinga. Kogda
   znacheniya perechislennye vyshe neopravdano bol'shie, mozhet
   postradat' proizvoditel'nost'.
   
   Maksimal'nyj razmer tablicy v 32 TB ne trebuet chtoby operacionnaya
   sistema podderzhivala fajly bol'shih razmerov. Bol'shie tablicy
   hranyatsya kak mnozhestvo fajlov razmerom v 1 GB, tak chto
   ogranicheniya, kotorye nakladyvaet fajlovaya sistema ne vazhny.
   
   Maksimal'nyj razmer tablicy i maksimal'noe kolichestvo kolonok mogut
   byt' uvelicheny v chetyre raza, esli razmer bloka po umolchaniyu budet
   uvelichen do 32k.
   
    4.6) Kak mnogo diskovogo prostranstva v baze dannyh nuzhno dlya sohraneniya
    dannyh iz obychnogo tekstovogo fajla?
    
   SUBD PostgreSQL mozhet potrebovat'sya diskovogo prostranstva do 5 raz
   bol'she dlya sohraneniya dannyh iz prostogo tekstovogo fajla.
   
   V kachestve primera, rassmotrim fajl v 100,000 strok v kazhdoj, iz
   kotoryh celoe chislo i tekstovoe opisanie. Pri `etom dlina teksta, v
   srednem, sostavlyaet 20 bajt. Razmer prostogo fajla sostavit 2.8 MB.
   Razmer bazy PostgreSQL, soderzhaschej `eti zhe dannye sostavit
   priblizitel'no 6.4 MB iz kotoryh:
    32 bajt: na kazhdyj zagolovok zapisi (priblizitel'no)
  + 24 bajta: odno pole s celochislennym tipom i odno tekstovoe pole
  +  4 bajta: ukazatel' na stranice dlya vsej zapisi
   ----------------------------------------
    60 bajt na zapis'

   Razmer stranicy dannyh v PostgreSQL sostavlyaet 8192 bajt (8 KB), tak chto:

   8192 bajt na stranicu
   ---------------------   =  136 zapisej na stranicu BD (okruglionno)
     60 bajt na zapis'

     100000 strok dannyh
   ----------------------- =  735 stranic v BD (okruglionno)
   128 zapisej na stranicu

   735 stranic BD * 8192 bajt na stranicu = 6,021,120 bajt (6 MB)

   Indeksy ne trebuyut tak mnogo, no poskol'ku oni sozdayutsya dlya
   bol'shogo kolichestva dannyh, oni takzhe mogut byt' veliki.
   
   Znacheniya NULL hranyatsya kak bitovye karty i po`etomu oni zanimayut
   ochen' malo mesta.
   
    4.7) Kak mne ubedit'sya, chto suschestvuyut nuzhnye mne tablicy, indeksy,
    bazy dannyh i pol'zovateli?
    
   psql imeet neskol'ko komand, nachinayuschihsya s obratnoj kosoj
   cherty, dlya togo chtoby prosmatrivat' takuyu informaciyu. Ispol'zujte
   \? dlya togo, chtoby uvidet' `eti komandy. Takzhe suschestvuyut
   sistemnye tablicy, imya kotoryh nachinaetsya na pg_ i v kotoryh takzhe
   soderzhitsya `eta informaciya. Eschio, psql -l pokazhet spisok vseh
   baz dannyh.
   
   Takzhe smotrite fajl pgsql/src/tutorial/syscat.source. V nem
   predstavleny mnogie operatory SELECT kotorye nuzhny dlya polucheniya
   informacii iz sistemnyh tablic bazy dannyh.
   
    4.8) U menya medlenno rabotayut zaprosy ili ne proishodit ispol'zovaniya
    indeksov. Pochemu?
    
   Indeksy ne ispol'zuyutsya dlya kazhdogo zaprosa avtomaticheski. Oni
   ispol'zuyutsya tol'ko esli tablica bol'she minimal'nogo razmera i
   zapros vybiraet tol'ko malen'kij procent zapisej v tablice. Tak
   ustroeno, potomu chto dostup k disku s primeneniem randomizacii pri
   skanirovanii indeksov mozhet byt' medlennee, chem prostoe chtenie
   tablicy ili ee posledovatel'noe skanirovanie.
   
   CHtoby opredelit' neobhodimost' ispol'zovaniya indeksa dlya kakoj-libo
   tablicy, PostgreSQL dolzhen imet' statistiku po `etoj tablice. `Eta
   statistika sobiraetsya pri ispol'zovanii VACUUM ANALYZE ili prosto
   ANALYZE. Ispol'zuya statistiku, optimizator uznaet o tom kak mnogo
   zapisej v tablice i esli on dolzhen ispol'zovat' indeksy, to on mozhet
   prinimat' luchshie resheniya. Statistika takzhe vliyaet na opredelenie
   optimal'nogo poryadka svyazyvaniya i metoda svyazyvaniya. Sbor
   statistiki dolzhen periodicheski vypolnyatsya pri izmenenii
   soderzhimogo tablicy.
   
   Obychno indeksy ne ispol'zuyutsya dlya ORDER BY ili dlya vypolneniya
   svyazyvanij. Posledovatel'nyj perebor sleduyuschij za yavnoj
   sortirovkoj obychno bystree, chem poisk po indeksam v bol'shoj
   tablice. Odnako, ORDER BY chasto kombiniruetsya s LIMIT i v `etom
   sluchae indeks budet ispol'zovat'sya, poskol'ku pri vypolnenii budet
   vozvraschat'sya nebol'shaya chast' tablicy. Fakticheski MAX() i MIN()
   ne ispol'zuyut indeksy, no indeks ispol'zuetsya pri postroenii
   zaprosov s ORDER BY i LIMIT:
    SELECT col
    FROM tab
    ORDER BY col [ DESC ]
    LIMIT 1;

   Esli vam kazhetsya, chto optimizator nekorrektno vybiraet
   posledovatel'nyj perebor, ispol'zujte SET enable_seqscan TO 'off' i
   zapustite testy, chtoby uvidet', ne stalo-li skanirovanie indeksov
   bystree.
   
   Kogda ispol'zuyutsya operacii s shablonami, naprimer LIKE ili ~,
   indeksy mogut byt' ispol'zovany v sleduyuschih sluchayah:
     * Nachalo stroki poiska dolzhno sovpadat' s nachalom iskomoj stroki,
       t.e.:
          + LIKE shablony ne dolzhny nachinat'sya s %..
          + ~ shablony regulyarnyh vyrazhenij dolzhna nachinat'sya na ^.
     * Stroka poiska ne dolzhna nachinat'sya s simvola klassa, t.e.
       [a-e].
     * Poisk nezavisimyj ot registra, takoj kak ILIKE i ~* ne ispol'zuet
       indeksy. Vmesto nego, ispol'zujte funkcional'nye indeksy, kotorye
       opisyvayutsya v sekcii 4.12.
     * Vo vremya initdb dolzhna ispol'zovat'sya lokal' po umolchaniyu C,
       potomu chto ne suschestvuet vozmozhnosti uznat' next-greater
       simvol dlya ne-C lokali. Vy mozhete dlya takih sluchaev sozdat'
       special'nyj indeks
        text_pattern_ops

       kotoryj rabotaet tol'ko dlya
        LIKE

       indeksirovaniya.
       
   V vypuskah do versii 8.0, indeksy chasto nel'zya bylo ispol'zovat',
   esli tipy dannyh tochno ne sovpadali s indeksnymi tipami kolonok. `Eto
   osobenno kasalos' int2, int8 i numeric indeksov kolonok.
   
    4.9) Kak posmotret' na to, kak optimizator vypolnyaet moj zapros?
    
   Smotrite stranicu rukovodstva posvyaschennuyu EXPLAIN.
   
    4.10) CHto takoe R-tree indeks?
    
   R-tree indeks ispol'zuetsya dlya indeksirovaniya prostranstvennyh
   dannyh. Indeks h`esha ne mozhet upravlyat' poiskami diapazona. B-tree
   indeks upravlyaet tol'ko poiskami diapazona v odnom izmerenii. R-tree
   indeks mozhet upravlyat' mnogorazmernymi dannymi. Naprimer, esli
   R-tree indeks mozhet byt' vstroen v atribut tipa point, to sistema
   mozhet bolee `effektivno otvetit' na zapros tipa "vybrat' vse tochki
   vnutri zadannogo chetyrehugol'nika."
   
   Kanonicheskij istochnik, opisyvayuschij pervonachal'noe sozdanie
   R-tree `eto:
   
   Guttman, A. "R-trees: A Dynamic Index Structure for Spatial
   Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of
   Data, 45-57.
   
   Vy mozhete najti `etot dokument v knige Stounbrejkera "Readings in
   Database Systems".
   
   Vstroennnye R-tree mogut upravlyat' poligonami i boksami. V teorii,
   R-tree mogut byt' rasshireny dlya upravleniya bol'shim kolichestvom
   izmerenij. Na praktike, rasshirenie R-tree trebuet nekotoryh usilij i
   u nas, v dannyj moment, net kakoj-libo dokumentacii o tom, kak `eto
   sdelat'.
   
    4.11) CHto takoe Genetic Query Optimizer?
    
   Modul' GEQO proizvodit bystruyu optimizaciyu zaprosa, kogda proishodit
   svyazyvanie mnogih tablic cherez Genetic Algorithm (GA). `Eto
   pozvolyaet upravlyat' bol'shimi zaprosami na svyazyvanie cherez
   neistoschayuschij poisk.
   
    4.12) Kak mne vypolnit' poisk regulyarnogo vyrazheniya i poisk nezavisimyj
    ot registra bukv poisk regulyarnogo vyrazheniya? Kak mne ispol'zovat'
    indeks dlya poiska nezavisimogo ot registra bukv?
    
   Operator ~ proizvodit poisk regulyarnogo vyrazheniya, a operator ~*
   proizvodit nezavisimyj ot registra bukv poisk regulyarnogo
   vyrazheniya. Nezavisimyj ot registra variant LIKE nazyvaetsya ILIKE.
   
   Nezavisimoe ot registra sravnenie obychno vyrazhaetsya tak:
    SELECT *
    FROM tab
    WHERE lower(col) = 'abc';

   `Eta konstrukciya ne budet ispol'zovat' standartnyj indeks. Odnako,
   esli vy sozdadite funkcional'nyj indeks, on budet ispol'zovan:
    CREATE INDEX tabindex ON tab (lower(col));

    4.13) Kak ya mogu opredelit', chto znachenie polya ravno NULL v kakom-libo
    zaprose?
    
   Vy prosto sravnivaete znachenie s IS NULL i IS NOT NULL.
   
    4.14) Kakovy otlichiya mezhdu raznymi simvol'nymi tipami?
    
Tip            Vnutrennee imya   Zamechaniya
--------------------------------------------------
VARCHAR(n)      varchar         razmer zadaet maksimal'nuyu dlinu, net zapolnen
iya
CHAR(n)         bpchar          zapolnyaetsya pustotoj do fiksirovannoj dliny
TEXT            text            net zadavaemogo verhnego ogranicheniya ili dlin
y
BYTEA           bytea           massiv bajt peremennoj dliny (mozhno ispol'zova
t' null-bajt bez opaski)
"char"          char            odin simvol

   Vnutrennee imya vy mozhete uvidet', kogda smotrite sistemnye katalogi
   i v nekotoryh soobscheniyah ob oshibkah.
   
   Pervye chetyre tipa yavlyayutsya "varlena" tipami (t.e., pervye
   chetyre bajta na diske yavlyayutsya dlinnoj, za kotoroj sleduyut
   dannye). Takim obrazom, fakticheski ispol'zuemoe prostranstvo bol'she,
   chem oboznachennyj razmer. Odnako, `eti tipy dannyh takzhe poddayutsya
   szhatiyu ili mogut byt' sohraneny ne v strokom vide cherez TOAST, tak
   chto zanimaemoe diskovoe prostranstvo mozhet takzhe byt' i men'she,
   chem ozhidalos'.
   VARCHAR(n) - `eto luchshee reshenie, kogda nuzhno hranit' stroki
   peremennoj dliny, ne prevyshayuschie opredelennogo razmera. TEXT -
   `eto luchshee reshenie dlya strok neogranichennoj dliny, s maksimal'no
   dopustimoj dlinoj v 1 gigabajt.
   
   CHAR(n) - `eto luchshee reshenie dlya hraneniya strok, kotorye obychno
   imeyut odinakovuyu dlinu. CHAR(n) zapolnyaetsya pustotoj do zadannoj
   dliny, v to vremya kak VARCHAR(n) hranit tol'ko simvoly, iz kotoryh
   sostoit stroka. BYTEA ispol'zuetsya dlya hraneniya binarnyh dannyh,
   znacheniya kotoryh mogut vklyuchat' NULL bajty. Vse tipy opisannye
   zdes', imeyut shodnye harakteristiki proizvoditel'nosti.
   
    4.15.1) Kak mne sozdat' pole serial/s-avto-uvelicheniem?
    
   PostgreSQL podderzhivaet tip dannyh SERIAL. On avtomaticheski sozdaet
   posledovatel'nost'. Naprimer:
    CREATE TABLE person (
        id   SERIAL,
        name TEXT
    );

   avtomaticheski transliruetsya v:
    CREATE SEQUENCE person_id_seq;
    CREATE TABLE person (
        id   INT4 NOT NULL DEFAULT nextval('person_id_seq'),
        name TEXT
    );

   Smotrite podrobnosti o posledovatel'nostyah na stranice rukovodstva
   posvyaschennoj create_sequence. Vy takzhe mozhete ispol'zovat' kazhdoe
   pole OID v zapisi kak unikal'noe znachenie. Odnako, esli vam nuzhen
   damp i perezagruzka bazy dannyh, vam neobhodimo ispol'zovat' komandu
   pg_dump s opciej -o ili opciyu COPY WITH OIDS dlya sohraneniya
   znachenij polya OID.
   
    4.15.2) Kak mne poluchit' znachenie pri vstavke SERIAL?
    
   Odin iz sposobov sostoit v poluchenii sleduyuschego znacheniya SERIAL
   iz ob"ekta sequence s pomosch'yu funkcii nextval() pered vstavkoj i
   zatem vstavlyat' `eto znachenie yavno. Ispol'zujte tablicu-primer v
   4.15.1, primer v psevdoyazyke pokazhet kak `eto delaetsya:
    new_id = execute("SELECT nextval('person_id_seq')");
    execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

   Zatem vy dolzhny takzhe sohranit' novoe znachenie v peremennoj new_id
   dlya ego ispol'zovaniya v drugih zaprosah (naprimer takih kak vneshnij
   klyuch dlya tablicy person). Zametim, chto imya avtomaticheski
   sozdannogo ob"ekta SEQUENCE budet <table>_<serialcolumn>_seq, gde
   table i serialcolumn yavlyayutsya sootvetstvenno imenami vashej
   tablicy i vashej kolonki SERIAL.
   
   V kachestve al'ternativy, vy mozhete poluchit' naznachennoe znachenie
   SERIAL s pomosch'yu funkcii currval() posle provedeniya obychnoj
   operacii vstavki, naprimer
    execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
    new_id = execute("SELECT currval('person_id_seq')");

   I nakonec, vy mozhete ispol'zovat' znachenie OID, vozraschaemoe iz
   opertora INSERT chtoby uvidet' znachenie po umolchaniyu, chto
   predpolozhitel'no yavlyaetsya naimenee perenosimym na drugie platformy
   resheniem, k tomu zhe znachenie oid budet urezat'sya, kogda ono
   dostignet 4 milliardov. V Perl, ispol'zuya DBI s modulem Edmund
   Mergl'ya DBD::Pg, znachenie oid stanovitsya dostupnym cherez
   $sth->{pg_oid_status} posle $sth->execute().
   
    4.15.3) Ne mozhet li poluchit'sya tak, chto ispol'zovanie currval() i
    nextval() privedet k zaciklirovaniyu s drugimi pol'zovatelyami?
    
   Net. currval() vozvraschaet tekuschee znachenie, naznachennoe vashem
   backend'om, a ne drugimi pol'zovatelyami.
   
    4.15.4) Pochemu chisla iz moej posledovatel'nosti ne ispol'zuyutsya snova
    pri otmene tranzakcii? Pochemu sozdayutsya razryvy pri numeracii v kolonke,
    gde ya ispol'zuyu posledovatel'nost'/SERIAL?
    
   Dlya realizacii konkuretnosti, znacheniya posledovatel'nostej, pri
   neobhodimosti vydayutsya vo vremya zapuska tranzakcij i ne
   blokiruyutsya do polnogo vypolneniya tranzakcij. `Eto mozhet vyzyvat'
   razryvy v numeracii pri otmene tranzakcij.
   
    4.16) CHto takoe OID? CHto takoe TID?
    
   Polya OID sluzhat unikal'nymi idetifikatorami zapisej v PostgreSQL.
   Kazhdaya zapis', kotoraya sozdaiotsya v PostgreSQL poluchaet
   unikal'nyj OID. Vse znacheniya OID generiruemye vo vremya initdb
   imeyut znacheniya men'she 16384 (iz include/access/transam.h). Vse
   sozdannye pol'zovatelem OID imeyut bOl'shie znachenie. Po umolchaniyu,
   vse `eti OID yavlyayutsya unikal'nymi ne tol'ko vnutri kakoj-libo
   tablicy ili bazy dannyh, no i vnutri vsej SUBD PostgreSQL.
   
   PostgreSQL ispol'zuet OID v svoih vnutrennih sistemnyh tablicah dlya
   svyazi zapisej i tablic. Znacheniya OID mogut byt' ispol'zovany dlya
   identifikacii zadannyh pol'zovatelem zapisej, a takzhe ispol'zovat'sya
   pri svyazyvaniyah. Rekomenduetsya ispol'zovat' tip kolonki OID dlya
   hraneniya znachenij OID Vy mozhete sozdat' indeks na pole OID dlya
   bolee bystrogo dostupa.
   
   Znacheniya OID naznachayutsya dlya vseh novyh zapisej iz central'noj
   oblasti, kotorye ispol'zuyutsya vsemi vsemi bazami dannyh. Esli vy
   hotite izmenit' OID na kakoe-libo drugoe znachenie ili esli vy hotite
   sozdat' kopiyu tablicy s takimizhe OID, to `eto mozhno sdelat' tak:
        CREATE TABLE new_table(mycol int);
        SELECT oid AS old_oid, mycol INTO tmp_table FROM old_table;
        COPY tmp_table TO '/tmp/pgtable';
        COPY new_table WITH OIDS FROM '/tmp/pgtable';
        DROP TABLE tmp_table;

   OID hranitsya kak 4-h bajtnoe celoe i ne mozhet prevyshat' znachenie v
   4 milliarda. Odnako, esche nikto ne soobschil o tom, chto takoe
   proizoshlo, no my planiruem do togo kak `eto sluchit'sya izbavitsya ot
   `etogo ogranicheniya.
   
   TID ispol'zuetsya dlya identifikacii special'nyh fizicheskih zapisej s
   blochnymi i offset znacheniyami. TID izmenyaetsya posle togo kak
   zapisi byli izmeneny ili peregruzheny.
   
   TID ispol'zuetsya indeksnymi zapisyami v kachestve ukazatelya na
   fizicheskie zapisi.
   
    4.17) CHto oznachayut nekotorye terminy ispol'zuemye v PostgreSQL?
    
   Nekotoryj ishodnyj kod i staraya dokumentaciya ispol'zuyut
   obscheupotrebitel'nye terminy. Vot nekotorye iz nih:
     * table, relation, class
     * row, record, tuple
     * column, field, attribute
     * retrieve, select
     * replace, update
     * append, insert
     * OID, serial value
     * portal, cursor
     * range variable, table name, table alias
       
   Spisok obschih terminov po bazam dannyh mozhno najti na
   http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary
   /glossary.html
   
    4.18) Pochemu ya poluchayu oshibku "ERROR: Memory exhausted in
    AllocSetAlloc()"?
    
   Predpolozhitel'no u vas zakonchilas' virtual'naya pamyat' ili chto
   vashe yadro imeet malen'kij limit na opredelennye resursy. Popytajtes'
   pered zapuskom postmaster vypolnit' sleduyuschie komandy:
    ulimit -d 262144
    limit datasize 256m

   V zavisimosti ot komandnogo interpretatora shell, tol'ko odna iz
   dannyh komand vypolnitsya uspeshno, no ona pozvolit vam ustanovit'
   bol'shij segment dannyh processa i vozmozhno reshit problemu. `Eta
   komanda izmenyaet parametry tekuschego processa i vseh ego potomkov,
   sozdannyh posle eio zapuska. Esli u vas voznikla problema s SQL
   klientom, potomu chto backend vozvraschaet slishkom bol'shoj ob"em
   dannyh, popytajtes' vypolnit' `etu komandu pered zapuskom klienta.
   
    4.19) Kak mne uznat', kakaya versiya PostgreSQL zapuschena?
    
   Iz psql, naberite SELECT version();
   
    4.20) Pochemu pri rabote s moim bol'shim ob"ektom ya poluchayu oshibku
    "invalid large obj descriptor"?
    
   Vam nuzhno pri ispol'zovanii bol'shogo ob"ekta pomestit' v nachale
   BEGIN WORK i v konce COMMIT, a vnutri poluchivshegosya bloka lo_open
   ... lo_close.
   
   V nastoyaschij moment PostgreSQL trebuet, chtoby pri zakrytii
   bol'shogo ob"ekta proishodilo vypolnenie tranzakcii. Takim obrazom,
   pervaya zhe popytka sdelat' chto-libo s bol'shim ob"ektom, ne
   soblyudaya dannogo pravila privedet k soobscheniyu invalid large obj
   descriptor, tak kak kod vypolnyayuschij rabotu nad bol'shim ob"ektom
   (po krajnej mere v nastoyaschij moment) budet generirovat' soobschenie
   ob oshibke esli vy ne ispol'zuete tranzakciyu.
   
   Esli vy ispol'zuete takoj interfejs klienta kak ODBC, vam vozmozhno
   ponadobitsya ustanovit' auto-commit off.
   
    4.21) Kak mne sozdat' kolonku kotoraya po umolchaniyu budet soderzhat'
    tekuschee vremya?
    
   Ispol'zujte CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );

    4.22) Pochemu moi podzaprosy, ispol'zuyuschie IN tak medlenno rabotaeyut?
    
   V versiyah do 7.4, podzaprosy svyazyvalis' s roditel'skimi zaprosami
   cherez posledovatel'nyj perebor rezul'tatov pozaprosa dlya kazhdoj
   zapisi roditel'skogo zaprosa. Esli podzapros vozvraschaet tol'ko
   neskol'ko zapisej, a roditel'skij zapros vozvraschaet mnogo zapisej,
   IN rabotaet naibolee bystro. CHtoby uvelichit' skorost' v drugih
   zaprosah, zamenite IN na EXISTS:
    SELECT *
    FROM tab
    WHERE col IN (SELECT subcol FROM subtab);

   na:
    SELECT *
    FROM tab
    WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);

   CHtoby takaya konstrukciya rabotala bystro, kolonka subcol dolzhna
   byt' proindeksirovana.
   
   V versii 7.4 i vyshe, IN fakticheski ispol'zuet takoj zhe mehanizm
   svyazyvaniya kak i obychnye zaprosy, po`etomu predpochtitel'nym
   yavlyaetsya ispol'zovanie EXISTS
   .
   
    4.23) Kak mne vypolnit' vneshnee svyazyvanie?
    
   PostgreSQL podderzhivaet vneshnee svyazyvanie, ispol'zuya standartnyj
   sintaksis SQL. Vot dva primera:
    SELECT *
    FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

   ili
    SELECT *
    FROM t1 LEFT OUTER JOIN t2 USING (col);

   `Eto identichnye zaprosy svyazyvaniya t1.col i t2.col, takzhe
   vozvraschayut lyubye nesvyazannye zapisi v t1 (kotorye ne sovpadayut s
   t2). RIGHT svyazyvanie dolzhno dobavit' nesvyazannye zapisi t2. FULL
   svyazyvanie dolzhno vozvratit' sovpavshie zapisi plyus vse
   nesvyazannye zapisi iz t1 i t2. Slovo OUTER yavlyaetsya
   neobyazatel'nym i naznachaetsya v LEFT, RIGHT i FULL svyazyvaniyah.
   Obychnye svyazyvaniya nazyvayutsya INNER svyazyvaniya.
   
   V predyduschih versiyah, vneshnie svyazyvaniya mogli byt' `emulirovany
   ispol'zuya UNION i NOT IN. Naprimer, kogda proishodit svyazyvanie tab1
   i tab2, sleduyuschij zapros vypolnyaet vneshnee svyazyvanie dvuh
   tablic:
    SELECT tab1.col1, tab2.col2
    FROM tab1, tab2
    WHERE tab1.col1 = tab2.col1
    UNION ALL
    SELECT tab1.col1, NULL
    FROM tab1
    WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
    ORDER BY col1

    4.24) Kak vypolnyat' zaprosy, ispol'zuyuschie neskol'ko baz dannyh?
    
   Ne suschestvuet sposoba sozdat' zapros k bazam dannyh otlichnym ot
   tekuschej. Poskol'ku PostgreSQL zagruzhaet sistemnye katalogi
   specifichnye dlya bazy dannyh, neponyatno dazhe, kak dolzhen sebya
   vesti takoj mezhbazovyj zapros.
   
   contrib/dblink pozvolyaet zaprosy mezhdu bazami, ispol'zuya vyzovy
   funkcij. Razumeetsya, klient mozhet odnovremenno ustanavlivat'
   soedieneniya s razlichnymi bazami dannyh i takih obrazom ob"edinyat'
   informaciyu iz nih.
   
    4.25) Kak mne vernut' iz funkcii neskol'ko zapisej?
    
   V versii 7.3, vy mozhete legko vernut' neskol'ko zapisej ili kolonok
   iz kakoj-libo funkcii,
   http://techdocs.postgresql.org/guides/SetReturningFunctions
   .
   
    4.26) Pochemu ya ne mogu nadezhno sozdavat'/udalyat' vremennye tablicy v
    funkciyah PL/PgSQL?
    
   PL/PgSQL k`eshiruet soderzhimoe funkcii i odin iz negativnyh `effektov
   `etogo sostoit v tom, chto esli funkciya PL/PgSQL obraschaetsya k
   vremennoj tablice i `eta tablica pozdnee udalyaetsya i peresozdaetsya,
   a funkciya zatem vyzyvaetsya snova, to ee vyzov privedet k oshibke,
   potomu chto sk`eshirovannoe soderzhimoe funkcii soderzhit ukazatel' na
   staruyu vremennuyu tablicu. CHtoby reshit' `etu problemu, ispol'zujte
   EXECUTE dlya dostupa k vremennym tablicam v PL/PgSQL. Ispol'zovanie
   `etogo operatora zastavit zapros peregenerirovat'sya kazhdyj raz.
   
    4.27) Kakie opcii shifrovaniya suschestvuyut?
    
     * contrib/pgcrypto soderzhit mnogo funkcij shifrovaniya dlya
       ispol'zovaniya v SQL zaprosah.
     * Dlya shifrovaniya peredavaemyh dannyh ot klienta k serveru, na
       servere v fajle postgresql.conf, opciya ssl dolzhna byt'
       ustanovlena v true, v fajle pg_hba.conf dolzhna byt'
       sootvetstvuyuschaya zapis' host ili hostssl i na storone klienta
       sslmode ne dolzhen byt' zapreschion cherez disable. (Zametim, chto
       takzhe vozmozhno ispol'zovanie nezavisimyh vneshnih shifruyuschih
       transportov, takih kak stunnel ili ssh, vmesto sobstvennyh SSL
       soedinenij PostgreSQL).
     * Paroli pol'zovatelej k baze dannyh avtomaticheski shifruyutsya,
       pri sohranenii v versii 7.3. V predyduschih versiyah, vy dolzhny
       razreshit' opciyu PASSWORD_ENCRYPTION v postgresql.conf.
     * Server mozhno zapustit', ispol'zuya shifrovannuyu fajlovuyu
       sistemu.
     _________________________________________________________________
   
                          Rasshireniya PostgreSQL
                                      
    5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya zapuskayu
    ee v psql, pochemu ya poluchayu core dump?
    
   Problema mozhet zaklyuchat'sya v neskol'kih veschah. Popytajtes'
   sperva protestirovat' vashu funkciyu v otdel'noj samostoyatel'noj
   programme.
   
    5.2) Kak ya mogu vnesti nekotorye klassnye novye tipy i funkcii v
    PostgreSQL?
    
   Otprav'te vashi rasshireniya v spisok rassylki pgsql-hackers i oni po
   vozmozhnosti budut pomescheny v podkatalog contrib/.
   
    5.3) Kak mne napisat' C funkciyu, vozvraschayuschuyu zapis'?
    
   V versiyah PostgreSQL, nachinaya s 7.3, funkcii, vozvraschayuschie
   tablicy polnost'yu podderzhivayutsya v C, PL/PgSQL i SQL. Podrobnosti
   smotrite v Rukovodstve Programmista. Primer vozvraschayuschej tablicu
   funkcii, napisannoj na C, mozhno najti v contrib/tablefunc.
   
    5.4) YA izmenil ishodnyj fajl. Pochemu posle perekompilyacii ya ne vizhu
    izmenenij?
    
   Fajly Makefile ne imeyut pravil'nyh zavisimostej dlya include fajlov.
   Vy dolzhny vypolnit' make clean i zatem make. Esli vy ispol'zuete GCC
   vy mozhete ispol'zovat' opciyu --enable-depend v configure chtoby
   poruchit' kompilyatoru avtomaticheski otslezhivat' zavisimosti.