aboutsummaryrefslogtreecommitdiff
path: root/doc/src/sgml/advanced.sgml
blob: 7876eac4104451d477581ff0e2edd9057d1107d4 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.16 2000/09/29 20:21:33 petere Exp $
-->

 <chapter id="advanced">
  <title>Advanced <productname>Postgres</productname> <acronym>SQL</acronym> Features</title>

  <para>
   Having covered the basics  of  using
   <productname>Postgres</productname> <acronym>SQL</acronym>  to
   access your data, we will now discuss those features of
   <productname>Postgres</productname> that distinguish  it  from  conventional  data
   managers.   These  features  include  inheritance, time
   travel and non-atomic  data  values  (array-  and  
   set-valued attributes).
   Examples   in   this  section  can  also  be  found  in
   <filename>advance.sql</filename> in the tutorial directory.
   (Refer to <xref linkend="QUERY"> for how to use it.)
  </para>

  <sect1 id="inheritance">
   <title>Inheritance</title>

   <para>
    Let's create two classes. The capitals  class  contains
    state  capitals  which  are also cities. Naturally, the
    capitals class should inherit from cities.

    <programlisting>
CREATE TABLE cities (
    name            text,
    population      float,
    altitude        int     -- (in ft)
);

CREATE TABLE capitals (
    state           char(2)
) UNDER cities;
    </programlisting>

    In this case, an  instance  of  capitals  <firstterm>inherits</firstterm>  all
    attributes  (name,  population,  and altitude) from its
    parent, cities.  The type  of  the  attribute  name  is
    <type>text</type>,  a  native  <productname>Postgres</productname>
    type  for variable length
    ASCII strings.  The type of the attribute population is
    <type>float</type>,  a  native <productname>Postgres</productname>
    type for double precision
    floating point numbers.  State capitals have  an  extra
    attribute, state, that shows their state.
    In <productname>Postgres</productname>,
    a  class  can inherit from zero or more other classes,
    and a query can reference either  all  instances  of  a
    class  or  all  instances  of  a  class plus all of its
    descendants.

    <note>
     <para>
      The inheritance hierarchy is a  directed  acyclic graph.
     </para>
    </note>
   </para>

   <para>
    For example, the  following  query finds the  names  of  all  cities,
    including  state capitals, that are located at an altitude 
    over 500ft, the query is:

    <programlisting>
SELECT c.name, c.altitude
    FROM cities c
    WHERE c.altitude > 500;
    </programlisting>

    which returns:

    <programlisting>
+----------+----------+
|name      | altitude |
+----------+----------+
|Las Vegas | 2174     |
+----------+----------+
|Mariposa  | 1953     |
+----------+----------+
|Madison   | 845      |
+----------+----------+
    </programlisting>
   </para>

   <para>
    On the other hand, the  following  query  finds
    all  the cities, but not capital cities 
    that are situated at an attitude of 500ft or higher:

    <programlisting>
SELECT name, altitude
    FROM ONLY cities
    WHERE altitude &gt; 500;

+----------+----------+
|name      | altitude |
+----------+----------+
|Las Vegas | 2174     |
+----------+----------+
|Mariposa  | 1953     |
+----------+----------+
    </programlisting>         
   </para>

   <para>
    Here the <quote>ONLY</quote> before cities indicates that the query should
    be  run over only cities and not classes below cities 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 <quote>ONLY</quote> notation.
   </para>

   <note>
    <title>Deprecated</title> 
    <para>
     In previous versions of <productname>Postgres</productname>, the
     default was not to get access to child tables. This was found to
     be error prone and is also in violation of SQL. Under the old
     syntax, to get the sub-classes you append "*" to the table name.
     For example
<programlisting>
SELECT * from cities*;
</programlisting>
     To get the old behavior, the set configuration option
     <literal>SQL_Inheritance</literal> to off, e.g.,
<programlisting>
SET SQL_Inheritance TO OFF;
</programlisting>
     or add a line in your <filename>postgresql.conf</filename> file.
    </para>
   </note>
  </sect1>

  <sect1 id="non-atomic-values">
   <title>Non-Atomic Values</title>

   <para>
    One  of  the tenets of the relational model is that the
    attributes of a relation are atomic.
    <productname>Postgres</productname> does not
    have  this  restriction; attributes can themselves contain 
    sub-values that can be  accessed  from  the  query
    language.   For example, you can create attributes that
    are arrays of base types.
   </para>

   <sect2>
    <title>Arrays</title>

    <para>
     <productname>Postgres</productname> allows attributes of an
     instance to be defined
     as  fixed-length  or  variable-length multi-dimensional
     arrays. Arrays of any base type  or  user-defined  type
     can  be created. To illustrate their use, we first create a 
     class with arrays of base types.

     <programlisting>
CREATE TABLE SAL_EMP (
    name            text,
    pay_by_quarter  int4[],
    schedule        text[][]
);
     </programlisting>
    </para>

    <para>
     The above query will create a class named SAL_EMP  with
     a  <firstterm>text</firstterm>  string (name), a one-dimensional
     array of <firstterm>int4</firstterm>
     (pay_by_quarter),  which  represents   the   employee's
     salary by quarter and a two-dimensional array of
     <firstterm>text</firstterm>
     (schedule),  which  represents  the  employee's  weekly
     schedule.   Now  we  do  some  <firstterm>INSERTS</firstterm>s;
     note that when
     appending to an array, we  enclose  the  values  within
     braces  and  separate  them  by commas.  If you know
     <firstterm>C</firstterm>,
     this is not unlike the syntax for  initializing  structures.

     <programlisting>
INSERT INTO SAL_EMP
    VALUES ('Bill',
    '{10000, 10000, 10000, 10000}',
    '{{"meeting", "lunch"}, {}}');

INSERT INTO SAL_EMP
    VALUES ('Carol',
    '{20000, 25000, 25000, 25000}',
    '{{"talk", "consult"}, {"meeting"}}');
     </programlisting>

     By  default,  <productname>Postgres</productname>  uses  the
     "one-based" numbering
     convention for arrays -- that is, an array  of  n  elements
     starts with array[1] and ends with array[n].
     Now,  we  can  run  some queries on SAL_EMP.  First, we
     show how to access a single element of an  array  at  a
     time.   This query retrieves the names of the employees
     whose pay changed in the second quarter:

     <programlisting>
SELECT name
    FROM SAL_EMP
    WHERE SAL_EMP.pay_by_quarter[1] &lt;&gt;
    SAL_EMP.pay_by_quarter[2];

+------+
|name  |
+------+
|Carol |
+------+
     </programlisting>
    </para>

    <para>
     This query retrieves  the  third  quarter  pay  of  all
     employees:
     
     <programlisting>
SELECT SAL_EMP.pay_by_quarter[3] FROM SAL_EMP;


+---------------+
|pay_by_quarter |
+---------------+
|10000          |
+---------------+
|25000          |
+---------------+
     </programlisting>
    </para>

    <para>
     We  can  also  access  arbitrary slices of an array, or
     subarrays.  This query  retrieves  the  first  item  on
     Bill's schedule for the first two days of the week.

     <programlisting>
SELECT SAL_EMP.schedule[1:2][1:1]
    FROM SAL_EMP
    WHERE SAL_EMP.name = 'Bill';

+-------------------+
|schedule           |
+-------------------+
|{{"meeting"},{""}} |
+-------------------+
     </programlisting>
    </para>
   </sect2>
  </sect1>

  <sect1 id="more-advanced">
   <title>More Advanced Features</title>

   <para>
    <productname>Postgres</productname> has many features not touched
    upon in this
    tutorial introduction, which has been oriented toward newer users of
    <acronym>SQL</acronym>.
    These are discussed in more detail in both the User's and
    Programmer's Guides.
   </para>

  </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:
-->