[plpgdoc-commit] doc/sgml advanced.sgml,1.1.1.1,1.2 biblio.sgml,1.1.1.1,1.2 query.sgml,1.1.1.1,1.2

[<ma...@us...>]

Update of /cvsroot/polishpgdoc/doc/sgml
In directory usw-pr-cvs1:/tmp/cvs-serv17999

Modified Files:
	advanced.sgml biblio.sgml query.sgml 
Log Message:
A.L.E.C. czuwa!


Index: advanced.sgml
===================================================================
RCS file: /cvsroot/polishpgdoc/doc/sgml/advanced.sgml,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** advanced.sgml	27 Apr 2002 18:30:38 -0000	1.1.1.1
--- advanced.sgml	17 Jun 2002 20:27:07 -0000	1.2
***************
*** 4,31 ****
  
   <chapter id="tutorial-advanced">
!   <title>Advanced Features</title>
  
    <sect1 id="tutorial-advanced-intro">
!    <title>Introduction</title>
  
     <para>
!     In the previous chapter we have covered the basics of using
!     <acronym>SQL</acronym> to store and access your data in
!     <productname>PostgreSQL</productname>.  We will now discuss some
!     more advanced features of <acronym>SQL</acronym> that simplify
!     management and prevent loss or corruption of your data.  Finally,
!     we will look at some <productname>PostgreSQL</productname>
!     extensions.
     </para>
  
     <para>
!     This chapter will on occasion refer to examples found in <xref
!     linkend="tutorial-sql"> to change or improve them, so it will be
!     of advantage if you have read that chapter.  Some examples from
!     this chapter can also be found in
!     <filename>advanced.sql</filename> in the tutorial directory.  This
!     file also contains some example data to load, which is not
!     repeated here.  (Refer to <xref linkend="tutorial-sql-intro"> for
!     how to use the file.)
     </para>
    </sect1>
--- 4,29 ----
  
   <chapter id="tutorial-advanced">
!   <title>Zaawansowane w³a¶ciwo¶ci</title>
  
    <sect1 id="tutorial-advanced-intro">
!    <title>Wprowadzenie</title>
  
     <para>
!     W poprzednim rozdziale poznali¶my podstawy zastosowania
!     <acronym>SQL'a</acronym> do przechowywania danych i dostêpu do nich
!     w <productname>PostgreSQL'u</productname>.  Teraz omówimy bardziej zaawansowane 
!     w³a¶ciwo¶ci jêzyka <acronym>SQL</acronym>, które u³atwiaj± zarz±dzanie oraz
!     zabezpieczaj± przed utrat± lub uszkodzeniem danych. W koñcu
!     poznamy niektóre rozszerzenia <productname>PostgreSQL'a</productname>.
     </para>
  
     <para>
!     Niniejszy rozdzia³ bêdzie odwo³ywa³ siê do przyk³adów 
!     zamieszczonych w <xref
!     linkend="tutorial-sql"> w celu ich zmiany i ulepszeñ, wiêc 
!     wskazane jest zapoznanie siê z tym rozdzia³em. Niektóre 
!     z przyk³adów mo¿na znale¼æ w <filename>advanced.sql</filename> w katalogu 
!     z tutorialem. Plik ten zawiera te¿ inne przyk³ady wprowadzania 
!     danych, nie wspomniane tutaj.  (Zobacz jak u¿yæ ten plik w <xref linkend="tutorial-sql-intro">).
     </para>
    </sect1>
***************
*** 33,49 ****
  
    <sect1 id="tutorial-views">
!    <title>Views</title>
  
     <indexterm zone="tutorial-views">
!     <primary>view</primary>
     </indexterm>
  
     <para>
!     Refer back to the queries in <xref linkend="tutorial-join">.
!     Suppose the combined listing of weather records and city location
!     is of particular interest to your application, but you don't want
!     to type the query each time you need it.  You can create a
!     <firstterm>view</firstterm> over the query, which gives a name to
!     the query that you can refer to like an ordinary table.
  
  <programlisting>
--- 31,47 ----
  
    <sect1 id="tutorial-views">
!    <title>Widoki</title>
  
     <indexterm zone="tutorial-views">
!     <primary>widok</primary>
     </indexterm>
  
     <para>
!     Odwo³ajmy siê do zapytañ z <xref linkend="tutorial-join">.
!     Zak³adamy, ¿e ³±czona lista rekordów pogody oraz po³o¿enia miast
!     jest szczególnie wa¿na w naszej aplikacji ale nie chcemy wprowadzaæ
!     zapytania za ka¿dym razem, gdy jest potrzebne.  Mo¿emy stworzyæ
!     <firstterm>widok</firstterm> oparty na zapytaniu, nadaj±c mu nazwê do której bêdziemy 
!     mogli odwo³ywaæ siê jak do zwyk³ej tabeli.
  
  <programlisting>
***************
*** 58,70 ****
  
     <para>
!     Making liberal use of views is a key aspect of good SQL database
!     design.  Views allow you to encapsulate the details of the
!     structure of your tables, which may change as your application
!     evolves, behind consistent interfaces.
     </para>
  
     <para>
!     Views can be used in almost any place a real table can be used.
!     Building views upon other views is not uncommon.
     </para>
    </sect1>
--- 56,70 ----
  
     <para>
!     Tworzenie widoków o szerokim zastosowaniu jest kluczowym
!     aspektem dobrego projektowania SQL'owych baz danych.
!     Widoki pozwalaj± odseparowaæ szczegó³ow± strukturê tabel,
!     która mo¿e siê zmieniaæ wraz z rozwojem aplikacji, niezale¿nie
!     od zastosowanych interfejsów.
     </para>
  
     <para>
!     Widoku mog± byæ stosowane prawie zawsze w miejsce 
!     rzeczywistych tabel.  Budowanie widoków z innych widoków 
!     nie jest niczym niezwyk³ym.
     </para>
    </sect1>
***************
*** 72,112 ****
  
    <sect1 id="tutorial-fk">
!    <title>Foreign Keys</title>
  
     <indexterm zone="tutorial-fk">
!     <primary>foreign key</primary>
     </indexterm>
  
     <indexterm zone="tutorial-fk">
!     <primary>referential integrity</primary>
     </indexterm>
  
     <para>
!     Recall the <classname>weather</classname> and
!     <classname>cities</classname> tables from <xref
!     linkend="tutorial-sql">.  Consider the following problem:  You
!     want to make sure that no one can insert rows in the
!     <classname>weather</classname> table that do not have a matching
!     entry in the <classname>cities</classname> table.  This is called
!     maintaining the <firstterm>referential integrity</firstterm> of
!     your data.  In simplistic database systems this would be
!     implemented (if at all) by first looking at the
!     <classname>cities</classname> table to check if a matching record
!     exists, and then inserting or rejecting the new
!     <classname>weather</classname> records.  This approach has a
!     number of problems and is very inconvenient, so
!     <productname>PostgreSQL</productname> can do this for you.
     </para>
  
     <para>
!     The new declaration of the tables would look like this:
  
  <programlisting>
! CREATE TABLE cities (
  	city		varchar(80) primary key,
  	location	point
  );
  
! CREATE TABLE weather (
  	city		varchar(80) references cities,
  	temp_lo		int,
--- 72,111 ----
  
    <sect1 id="tutorial-fk">
!    <title>Klucze obce</title>
  
     <indexterm zone="tutorial-fk">
!     <primary>klucz obcy</primary>
     </indexterm>
  
     <indexterm zone="tutorial-fk">
!     <primary>integralno¶æ referencyjna</primary>
     </indexterm>
  
     <para>
!     Wracaj±c do tabel <classname>weather</classname> i <classname>cities</classname> z <xref
!     linkend="tutorial-sql">.  Rozwa¿my 
!     nastêpuj±cy problem:  Chcieliby¶my mieæ pewno¶æ, ¿e 
!     nikt nie mo¿e wstawiæ wierszy do tabeli <classname>weather</classname>, 
!     który nie ma odpowiedniego wpisu w tabeli <classname>cities</classname>.  
!     Jest to nazywane <firstterm>integralno¶ci± referencyjn±</firstterm> danych.  
!     W prymitywnych systemach baz danych mo¿na by³oby to 
!     zaimplementowaæ przez sprawdzenie, czy pasuj±cy rekord istnieje w tabeli
!     <classname>cities</classname>, a nastêpnie wstawienie lub odrzucenie nowych rekordów
!     tabeli <classname>weather</classname>.  To podej¶cie napotyka wiele trudno¶ci
!     i jest bardzo k³opotliwe, dlatego <productname>PostgreSQL</productname> robi to za nas.
     </para>
  
     <para>
!     Nowa deklaracja tabel powinna wygl±daæ tak:
  
  <programlisting>
! CREATE TABLE cities 
! (
  	city		varchar(80) primary key,
  	location	point
  );
  
! CREATE TABLE weather 
! (
  	city		varchar(80) references cities,
  	temp_lo		int,
***************
*** 118,122 ****
  </programlisting>
  
!     Now try inserting an invalid record:
  
  <programlisting>
--- 117,121 ----
  </programlisting>
  
!     Teraz spróbuj wstawiæ niepoprawne dane:
  
  <programlisting>
***************
*** 125,129 ****
  
  <screen>
! ERROR:  &lt;unnamed&gt; referential integrity violation - key referenced from weather not found in cities
  </screen>
  
--- 124,128 ----
  
  <screen>
! ERROR:  &lt;unnamed&gt; naruszenie integralno¶ci referencyjnej - klucz odnosz±cy siê do weather nie znaleziony w cities
  </screen>
  
***************
*** 131,140 ****
  
     <para>
!     The behavior of foreign keys can be finely tuned to your
!     application.  We will not go beyond this simple example in this
!     tutorial, but just refer you to the <citetitle>Reference
!     Manual</citetitle> for more information.  Making correct use of
!     foreign keys will definitely improve the quality of your database
!     applications, so you are strongly encouraged to learn about them.
     </para>
    </sect1>
--- 130,139 ----
  
     <para>
!     Dzia³anie kluczy obcych mo¿e mieæ zastosowanie w twoich aplikacjach.
!     Nie bêdziemy wychodziæ poza ten prosty przyk³ad, po wiêcej informacji
!     odsy³amy Ciê do <citetitle>Podrêcznika u¿ytkownika</citetitle>.  Prawid³owe zastosowanie 
!     kluczy obcych zdecydowanie podniesie jako¶æ Twoich aplikacji
!     bazodanowych, dlatego zachêcamy do lepszego poznania tego 
!     zagadnienia.
     </para>
    </sect1>
***************
*** 142,166 ****
  
    <sect1 id="tutorial-transactions">
!    <title>Transactions</title>
  
     <indexterm zone="tutorial-transactions">
!     <primary>transactions</primary>
     </indexterm>
  
     <para>
!     <firstterm>Transactions</> are a fundamental concept of all database
!     systems.  The essential point of a transaction is that it bundles
!     multiple steps into a single, all-or-nothing operation.  The intermediate
!     states between the steps are not visible to other concurrent transactions,
!     and if some failure occurs that prevents the transaction from completing,
!     then none of the steps affect the database at all.
     </para>
  
     <para>
!     For example, consider a bank database that contains balances for various
!     customer accounts, as well as total deposit balances for branches.
!     Suppose that we want to record a payment of $100.00 from Alice's account
!     to Bob's account.  Simplifying outrageously, the SQL commands for this
!     might look like
  <programlisting>
  UPDATE accounts SET balance = balance - 100.00
--- 141,165 ----
  
    <sect1 id="tutorial-transactions">
!    <title>Transakcje</title>
  
     <indexterm zone="tutorial-transactions">
!     <primary>transakcje</primary>
     </indexterm>
  
     <para>
!     <firstterm>Transakcje</> s± podstawow± w³asno¶ci± wszystkich systemów
!     baz danych.  Istot± transakcji jest ³±czenie nieograniczonej ilo¶ci
!     operacji w jedn±.  Stany po¶rednie miêdzy operacjami jednej 
!     transakcji nie s± widoczne dla innych transakcji i je¶li wyst±pi b³±d, 
!     uniemo¿liwiaj±cy ukoñczenie transakcji, wtedy ¿adna z operacji 
!     nie jest zapisywana do bazy.
     </para>
  
     <para>
!     Na przyk³ad, we¼my bankow± bazê danych, zawieraj±c± salda na
!     kontach ró¿nych klientów, jako ca³kowity depozyt wszystkich oddzia³ów
!     banku.  Przypu¶æmy, ¿e chcemy przelaæ 100.00 $ z konta Alice 
!     na konto Boba.  Bardzo upraszczaj±c, polecenia SQL mog± 
!     wygl±daæ tak:
  <programlisting>
  UPDATE accounts SET balance = balance - 100.00
***************
*** 173,252 ****
      WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
  </programlisting>
!     The details of these commands are not important here; the important
!     point is that there are several separate updates involved to accomplish
!     this rather simple operation.  Our bank's officers will want to be
!     assured that either all these updates happen, or none of them happen.
!     It would certainly not do for a system failure to result in Bob
!     receiving $100.00 that was not debited from Alice.  Nor would Alice long
!     remain a happy customer if she was debited without Bob being credited.
!     We need a guarantee that if something goes wrong partway through the
!     operation, none of the steps executed so far will take effect.  Grouping
!     the updates into a <firstterm>transaction</> gives us this guarantee.
!     A transaction is said to be <firstterm>atomic</>: from the point of
!     view of other transactions, it either happens completely or not at all.
     </para>
  
     <para>
!     We also want a
!     guarantee that once a transaction is completed and acknowledged by
!     the database system, it has indeed been permanently recorded
!     and won't be lost even if a crash ensues shortly thereafter.
!     For example, if we are recording a cash withdrawal by Bob,
!     we do not want any chance that the debit to his account will
!     disappear in a crash just as he walks out the bank door.
!     A transactional database guarantees that all the updates made by
!     a transaction are logged in permanent storage (i.e., on disk) before
!     the transaction is reported complete.
     </para>
  
     <para>
!     Another important property of transactional databases is closely
!     related to the notion of atomic updates: when multiple transactions
!     are running concurrently, each one should not be able to see the
!     incomplete changes made by others.  For example, if one transaction
!     is busy totalling all the branch balances, it would not do for it
!     to include the debit from Alice's branch but not the credit to
!     Bob's branch, nor vice versa.  So transactions must be all-or-nothing
!     not only in terms of their permanent effect on the database, but
!     also in terms of their visibility as they happen.  The updates made
!     so far by an open transaction are invisible to other transactions
!     until the transaction completes, whereupon all the updates become
!     visible simultaneously.
     </para>
  
     <para>
!     In <productname>PostgreSQL</>, a transaction is set up by surrounding
!     the SQL commands of the transaction with
!     <command>BEGIN</> and <command>COMMIT</> commands.  So our banking
!     transaction would actually look like
  <programlisting>
  BEGIN;
  UPDATE accounts SET balance = balance - 100.00
      WHERE name = 'Alice';
! -- etc etc
  COMMIT;
  </programlisting>
!     If, partway through the transaction, we decide we don't want to
!     commit (perhaps we just noticed that Alice's balance went negative),
!     we can issue the command <command>ROLLBACK</> instead of
!     <command>COMMIT</>, and all our updates so far will be canceled.
     </para>
  
     <para>
!     <productname>PostgreSQL</> actually treats every SQL statement as being
!     executed within a transaction.  If you don't issue a <command>BEGIN</>
!     command, 
!     then each individual statement has an implicit <command>BEGIN</> and
!     (if successful) <command>COMMIT</> wrapped around it.  A group of
!     statements surrounded by <command>BEGIN</> and <command>COMMIT</>
!     is sometimes called a <firstterm>transaction block</>.
     </para>
  
     <note>
      <para>
!      Some client libraries issue <command>BEGIN</> and <command>COMMIT</>
!      commands automatically, so that you may get the effect of transaction
!      blocks without asking.  Check the documentation for the interface
!      you are using.
      </para>
     </note>
--- 172,253 ----
      WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
  </programlisting>
!     Szczegó³y tych poleceñ nie s± tutaj wa¿ne; istotne jest, ¿e mamy
!     tutaj ³±czymy wiele poleceñ aktualizuj±cych w celu realizacji
!     tej jak¿e prostej operacji.  Pracownicy naszego banku chcieliby
!     mieæ pewno¶æ, ¿e ka¿da z tych operacji powiod³a siê albo ¿adna
!     nie odnios³a skutku.  Nie do przyjêcia jest sytuacja, gdy Bob otrzymuje
!     100.00 $, bez potr±cenia tej kwoty z konta Alice,  ani te¿ nie bêdzie
!     zachwycona Alice, gdy pieni±dze zostan± jej potr±cone,
!     a Bob nie zostanie sp³acony.  Musimy mieæ gwarancjê, ¿e 
!     gdyby która¶ czê¶æ operacji nie powiod³a siê, to ¿aden z kroków 
!     wykonanych wcze¶niej nie da efektu.  Grupowanie uaktualnieñ w 
!     jedn± <firstterm>transaction</> daje nam t± gwarancjê.  Mówi siê, ¿e transakcja
!     jest <firstterm>atomowa</>: z punktu widzenia transakcji, jest wykonywana w 
!    ca³o¶ci albo w ogóle.
     </para>
  
     <para>
!     Chcemy równie¿ zagwarantowania, ¿e transakcja zosta³a 
!     wykonana przez potwierdzenie z systemu bazodanowego. 
!     To znaczy, ¿e zosta³a rzeczywi¶cie zapisana na sta³e i nie
!     zostanie utracona nawet gdyby wkrótce pó¼niej nast±pi³a 
!     awaria.  Na przyk³ad je¶li zapisujemy podjêcie pieniêdzy przez
!     Boba, to nie chcemy ¿eby potr±cenie z jego konta zginê³o, tak
!     jakby po prostu wyszed³ z banku przez drzwi.  Transakcyjna baza
!     danych daje gwarancjê, ¿e wszystkie operacje wewn±trz transakcji
!     zostan± zapisane na trwa³ym no¶niku (np. dysku) zanim 
!     transakcja zostanie wykonana w ca³o¶ci.
     </para>
  
     <para>
!     Inn± wa¿n± w³a¶ciwo¶ci± transakcyjnych baz danych jest bliski
!     zwi±zek z zapisem operacji cz±stkowych: gdy wykonuje siê wiele 
!     transakcji, ¿adna nie powinna widzieæ niekompletnych zmian 
!     dokonanych przez inne transakcje.  Na przyk³ad, je¶li jedna 
!     transakcja jest zajêta sumowaniem depozytów w ka¿dym 
!     oddziale, nie powinna braæ pod uwagê debetu w oddziale Alice
!     bez uwzglêdniania zwy¿ki w oddziale Boba, ani odwrotnie.  
!     Transakcje musz± byæ wykonywane jako wszystko-lub-nic nie 
!     tylko z punktu widzenia trwa³ego efektu na bazie danych, ale 
!     równie¿ z punktu widzenia ich dzia³ania.  Operacje jednej 
!     transakcji s± niewidoczne dla innych dopóki nie zostanie ona 
!     wykonana w ca³o¶ci, potem efekt tych operacji stanie siê widoczny
!     rónocze¶nie.
     </para>
  
     <para>
!     W <productname>PostgreSQL'u</> transakcjê stanowi± polecenia SQL
!     otoczone komendami
!     <command>BEGIN</> i <command>COMMIT</>.  Tak wiêc, nasza transakcja
!     bankowa bêdzie wygl±daæ nastêpuj±co:
  <programlisting>
  BEGIN;
  UPDATE accounts SET balance = balance - 100.00
      WHERE name = 'Alice';
! -- itd.
  COMMIT;
  </programlisting>
!     Je¶li podczas wykonywania transakcji zdecydujemy, ¿e nie
!     chcemy jej zatwierdziæ (na przyk³ad stwierdzili¶my, ¿e saldo Alice
!     jest ujeme), mo¿emy u¿yæ komendê <command>ROLLBACK</> w miejsce
!     <command>COMMIT</> i wtedy wszystkie operacje wykonane dotychczas
!     zostana odwo³ane.
     </para>
  
     <para>
!     Obecnie <productname>PostgreSQL</> traktuje ka¿de polecenie SQL 
!     jak wykonywane wewn±trz transakcji.  Je¶li nie wprowadzisz 
!     polecenia <command>BEGIN</>, wtedy ka¿da indywidualna operacja 
!     zostanie otoczona <command>BEGIN</> i (je¶li siê powiod³a) <command>COMMIT</> 
!     wokó³ niej.  Grupa poleceñ otoczonych przez <command>BEGIN</> i <command>COMMIT</>
!     czasami nazywana jest <firstterm>blokiem transakcji</>.
     </para>
  
     <note>
      <para>
!      Niektóre biblioteki klienckie do³±czaj± komendy <command>BEGIN</> 
!      i <command>COMMIT</> automatycznie, wiêc mo¿esz otrzymaæ efekt
!      transakcji nie wiedz±c o tym.  Sprawd¼ dokumentacjê 
!      interfejsów, których u¿ywasz.
      </para>
     </note>
***************
*** 255,275 ****
  
    <sect1 id="tutorial-inheritance">
!    <title>Inheritance</title>
  
     <indexterm zone="tutorial-inheritance">
!     <primary>inheritance</primary>
     </indexterm>
  
     <para>
!     Inheritance is a concept from object-oriented databases.  It opens
!     up interesting new possibilities of database design.
     </para>
  
     <para>
!     Let's create two tables:  A table <classname>cities</classname>
!     and a table <classname>capitals</classname>.  Naturally, capitals
!     are also cities, so you want some way to show the capitals
!     implicitly when you list all cities.  If you're really clever you
!     might invent some scheme like this:
  
  <programlisting>
--- 256,276 ----
  
    <sect1 id="tutorial-inheritance">
!    <title>Dziedziczenie</title>
  
     <indexterm zone="tutorial-inheritance">
!     <primary>dziedziczenie</primary>
     </indexterm>
  
     <para>
!     Dziedziczenie jest w³a¶ciwo¶ci± obiektowo zorientowanych 
!     baz danych, która daje nowe interesuj±ce mo¿liwo¶ci projektowania
!     baz danych.
     </para>
  
     <para>
!     Utwórzmy dwie tabele:  tabelê <classname>cities</classname> (miasta)
!     i tabelê <classname>capitals</classname> (stolice).  Naturalnie, stolice s± równie¿ miastami
!     wiêc musimy w jaki¶ sposób je wyró¿niæ w¶ród miast.
!     Mo¿na zastosowaæ nastêpuj±cy schemat:
  
  <programlisting>
***************
*** 293,302 ****
  </programlisting>
  
!     This works OK as far as querying goes, but it gets ugly when you
!     need to update several rows, to name one thing.
     </para>
  
     <para>
!     A better solution is this:
  
  <programlisting>
--- 294,304 ----
  </programlisting>
  
!     Bêdzie to dzia³aæ dopóki wyszukujemy dane, ale je¶li bêdziemy
!     chcieli zaktualizowaæ kilka wierszy, aby zmieniæ jedn± rzecz, nie bêdzie
!     to wygl±daæ ³adnie.
     </para>
  
     <para>
!     Lepszym rozwi±zaniem bêdzie:
  
  <programlisting>
***************
*** 312,331 ****
  </programlisting>
  
!     In this case, a row of <classname>capitals</classname>
!     <firstterm>inherits</firstterm> all columns (<structfield>name</>,
!     <structfield>population</>, and <structfield>altitude</>) from its
!     <firstterm>parent</firstterm>, <classname>cities</classname>.  The
!     type of the column <structfield>name</structfield> is
!     <type>text</type>, a native <productname>PostgreSQL</productname>
!     type for variable length character strings.  State capitals have
!     an extra column, state, that shows their state.  In
!     <productname>PostgreSQL</productname>, a table can inherit from
!     zero or more other tables.
     </para>
  
     <para>
!     For example, the  following  query finds the  names  of  all  cities,
!     including  state capitals, that are located at an altitude 
!     over 500 ft.:
  
  <programlisting>
--- 314,330 ----
  </programlisting>
  
!     W tym wypadku wiersz tabeli <classname>capitals</classname>
!     <firstterm>dziedziczy</firstterm> wszystkie kolumny (<structfield>name</>,
!     <structfield>population</>, and <structfield>altitude</>) od swojego rodzica
!     <firstterm>parent</firstterm>, tabeli <classname>cities</classname>.  Kolumna <structfield>name</structfield> jest
!     typu <type>text</type>, przeznaczonego w <productname>PostgreSQL'u</productname>
!     dla ci±gów znakowych zmiennej d³ugo¶ci.  Stolice stanów
!     posiadaj± dodatkow± kolumnê state opisuj±c± w którym s± stanie.  
!     W <productname>PostgreSQL'u</productname> tabela mo¿e dziedziczyæ z wiêcej ni¿ jednej tabeli.
     </para>
  
     <para>
!     Dla przyk³adu, nastêpuj±ce zapytanie wyszukuje nazwy wszystkich miast
!     w³±cznie ze stolicami po³o¿onymi na wysoko¶ci powy¿ej 500 ft.:
  
  <programlisting>
***************
*** 335,339 ****
  </programlisting>
  
!     which returns:
  
  <screen>
--- 334,338 ----
  </programlisting>
  
!     a zwraca:
  
  <screen>
***************
*** 343,354 ****
   Mariposa  |     1953
   Madison   |      845
! (3 rows)
  </screen>
     </para>
  
     <para>
!     On the other hand, the  following  query  finds
!     all  the cities that are not state capitals and
!     are situated at an altitude of 500 ft. or higher:
  
  <programlisting>
--- 342,352 ----
   Mariposa  |     1953
   Madison   |      845
! (3 rek.)
  </screen>
     </para>
  
     <para>
!     Z drugiej strony, poni¿sze zapytanie wy¶wietli wszystkie miasta, nie bêd±ce
!     stolicami, usytuowane na wysoko¶ci powy¿ej 500 ft.:
  
  <programlisting>
***************
*** 363,379 ****
   Las Vegas |     2174
   Mariposa  |     1953
! (2 rows)
  </screen>         
     </para>
  
     <para>
!     Here the <literal>ONLY</literal> before <literal>cities</literal>
!     indicates that the query should be run over only the
!     <classname>cities</classname> table, and not tables below
!     <classname>cities</classname> in the inheritance hierarchy.  Many
!     of the commands that we have already discussed --
!     <command>SELECT</command>, <command>UPDATE</command> and
!     <command>DELETE</command> -- support this <literal>ONLY</literal>
!     notation.
     </para>
    </sect1>
--- 361,376 ----
   Las Vegas |     2174
   Mariposa  |     1953
! (2 rek.)
  </screen>         
     </para>
  
     <para>
!     Klauzula <literal>ONLY</literal> przed <literal>cities</literal>
!     oznacza, ¿e zapytanie powinno byæ wykonane tylko
!     na tabeli <classname>cities</classname>, a nie na tabelach dziedzicz±cych po
!     <classname>cities</classname>.
!     Do wielu komend, które ju¿ omówili¶my --
!     <command>SELECT</command>, <command>UPDATE</command> oraz
!     <command>DELETE</command> mo¿na stosowaæ klauzulê <literal>ONLY</literal>.
     </para>
    </sect1>
***************
*** 381,399 ****
  
    <sect1 id="tutorial-conclusion">
!    <title>Conclusion</title>
   
     <para>
!     <productname>PostgreSQL</productname> has many features not
!     touched upon in this tutorial introduction, which has been
!     oriented toward newer users of <acronym>SQL</acronym>.  These
!     features are discussed in more detail in both the
!     <citetitle>User's Guide</citetitle> and the
!     <citetitle>Programmer's Guide</citetitle>.
     </para>
  
     <para>
!     If you feel you need more introductory material, please visit the
!     <ulink url="http://www.postgresql.org">PostgreSQL web
!     site</ulink> for links to more resources.
     </para>
    </sect1>
--- 378,395 ----
  
    <sect1 id="tutorial-conclusion">
!    <title>Podsumowanie</title>
   
     <para>
!     <productname>PostgreSQL</productname> posiada wiele w³a¶ciwo¶ci nie wyszczególnionych
!     w tej czê¶ci dokumentacji, przeznaczonych dla bardziej 
!     zaawansowanych u¿ytkowników <acronym>SQL'a</acronym>.  W³a¶ciwo¶ci te
!     s± opisane bardziej szczegó³owo w <citetitle>Podrêczniku u¿ytkownika</citetitle> 
!     oraz <citetitle>Podrêczniku programisty</citetitle>.
     </para>
  
     <para>
!     Je¶li potrzebujesz wiêcej materia³ów wprowadzaj±cych odwied¼
!     <ulink url="http://www.postgresql.org">stronê PostgreSQL w Internecie</ulink>, na której znajdziesz wiele 
!     odno¶ników do dokumentacji.
     </para>
    </sect1>

Index: biblio.sgml
===================================================================
RCS file: /cvsroot/polishpgdoc/doc/sgml/biblio.sgml,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** biblio.sgml	27 Apr 2002 18:30:41 -0000	1.1.1.1
--- biblio.sgml	17 Jun 2002 20:27:08 -0000	1.2
***************
*** 4,26 ****
  
   <bibliography id="biblio">
!   <title>Bibliography</title>
  
    <para>
!    Selected references and readings for <acronym>SQL</acronym>
!    and <productname>PostgreSQL</productname>.
    </para>
  
    <para>
!    Some white papers and technical reports from the original
!    <productname>POSTGRES</productname> development team
!    are available at
     <ulink url="http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/papers/">
!     the University of California, Berkeley, Computer Science
!     Department web site</ulink>
    </para>
  
    <bibliodiv>
!    <title><acronym>SQL</acronym> Reference Books</title>
!    <para>Reference texts for <acronym>SQL</acronym> features.</para>
  
     <biblioentry id="BOWMAN93">
--- 4,25 ----
  
   <bibliography id="biblio">
!   <title>Bibliografia</title>
  
    <para>
!    Wybrane podrêczniki i opracowania na temat <acronym>SQL</acronym>
!    i <productname>PostgreSQL</productname>.
    </para>
  
    <para>
!    Wiele technicznych opracowañ zespo³u twórców
!    <productname>POSTGRES</productname> jest dostêpnych na stronie
     <ulink url="http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/papers/">
!     University of California, Berkeley, Computer Science
!     Department</ulink>
    </para>
  
    <bibliodiv>
!    <title>Podrêczniki<acronym>SQL</acronym></title>
!    <para>Opis w³a¶ciwo¶ci<acronym>SQL</acronym>.</para>
  
     <biblioentry id="BOWMAN93">
***************
*** 166,171 ****
  
    <bibliodiv>
!    <title>PostgreSQL-Specific Documentation</title>
!    <para>This section is for related documentation.</para>
  
     <biblioentry id="SIM98">
--- 165,170 ----
  
    <bibliodiv>
!    <title>Dokumentacja PostgreSQL</title>
!    <para>Ta czê¶æ dotyczy dokumentacji ¶ci¶le dotycz±cej postgresa.</para>
  
     <biblioentry id="SIM98">
***************
*** 184,191 ****
       </author>
      </authorgroup>
! <!--
!     <othercredit>
       <contrib>
!       with support by
       </contrib>
       <honorific>O. Univ. Prof. Dr.</honorific>
--- 183,189 ----
       </author>
      </authorgroup>
! <othercredit>
       <contrib>
!       przy wspó³pracy
       </contrib>
       <honorific>O. Univ. Prof. Dr.</honorific>
***************
*** 196,207 ****
       <surname>Seyr</surname>
      </othercredit>
! -->
      <abstract>
       <para>
!       Discusses SQL history and syntax, and describes the addition of
!       <literal>INTERSECT</> and <literal>EXCEPT</> constructs into
!       <productname>PostgreSQL</productname>.  Prepared as a Master's
!       Thesis with the support of O. Univ. Prof. Dr. Georg Gottlob and
!       Univ. Ass. Mag. Katrin Seyr at Vienna University of Technology.
       </para>
      </abstract>
--- 194,205 ----
       <surname>Seyr</surname>
      </othercredit>
! --</indexterm>
      <abstract>
       <para>
!       Omawia historiê i sk³adniê SQL oraz opisuje u¿ycie konstrukcji
!       <literal>INTERSECT</> i <literal>EXCEPT</> w <productname>PostgreSQL</productname>.  
!       Stworzona jako Tezy G³ówne z pomoc± 
!       O. Univ. Prof. Dr. Georg Gottlob i 
!       Univ. Ass. Mag. Katrin Seyr z Vienna University of Technology.
       </para>
      </abstract>
***************
*** 257,262 ****
  
    <bibliodiv>
!    <title>Proceedings and Articles</title>
!    <para>This section is for articles and newsletters.</para>
     
     <biblioentry id="OLSON93">
--- 255,260 ----
  
    <bibliodiv>
!    <title>Artyku³y i sprawozdania</title>
!    <para>W tej czê¶ci s± artyku³y i biuletyny.</para>
     
     <biblioentry id="OLSON93">

Index: query.sgml
===================================================================
RCS file: /cvsroot/polishpgdoc/doc/sgml/query.sgml,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** query.sgml	27 Apr 2002 18:31:02 -0000	1.1.1.1
--- query.sgml	17 Jun 2002 20:27:08 -0000	1.2
***************
*** 1,819 ****
! <!--
! $Header$
! -->
! 
!  <chapter id="tutorial-sql">
!   <title>The <acronym>SQL</acronym> Language</title>
! 
!   <sect1 id="tutorial-sql-intro">
!    <title>Introduction</title>
! 
[...1584 lines suppressed...]
!   </sect1>
! 
!  </chapter>
! 
! <!-- Keep this comment at the end of the file
! Local variables:
! mode:sgml
! sgml-omittag:nil
! sgml-shorttag:t
! sgml-minimize-attributes:nil
! sgml-always-quote-attributes:t
! sgml-indent-step:1
! sgml-indent-data:t
! sgml-parent-document:nil
! sgml-default-dtd-file:"./reference.ced"
! sgml-exposed-tags:nil
! sgml-local-catalogs:("/usr/lib/sgml/catalog")
! sgml-local-ecat-files:nil
! End:
! -->