mirror of
https://github.com/postgres/postgres.git
synced 2025-04-25 21:42:33 +03:00
Some minor improvements to the CE docs. Also fix a bit of SGML markup
elsewhere.
This commit is contained in:
parent
99d48695d4
commit
8bd1cbb86d
@ -1,4 +1,4 @@
|
|||||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.46 2005/11/01 23:19:05 neilc Exp $ -->
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.47 2005/11/03 00:51:43 neilc Exp $ -->
|
||||||
|
|
||||||
<chapter id="ddl">
|
<chapter id="ddl">
|
||||||
<title>Data Definition</title>
|
<title>Data Definition</title>
|
||||||
@ -1406,32 +1406,42 @@ SELECT * from cities*;
|
|||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
The benefits will normally be worthwhile only when a data table would
|
The benefits will normally be worthwhile only when a table would
|
||||||
otherwise be very large. That is for you to judge, though would not
|
otherwise be very large. The exact point at which a table will
|
||||||
usually be lower than the size of physical RAM on the database server.
|
benefit from partitioning depends on the application, although the
|
||||||
|
size of the table should usually exceed the physical memory of the
|
||||||
|
database server.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In <productname>PostgreSQL</productname> &version;, the following
|
The following partitioning types are supported by
|
||||||
partitioning types are supported:
|
<productname>PostgreSQL</productname> &version;:
|
||||||
|
|
||||||
<itemizedlist>
|
<variablelist>
|
||||||
<listitem>
|
<varlistentry>
|
||||||
<para>
|
<term>Range Partitioning</term>
|
||||||
"Range Partitioning" where the table is partitioned along a
|
|
||||||
"range" defined by a single column or set of columns, with no
|
|
||||||
overlap between partitions. Examples might be a date range or a
|
|
||||||
range of identifiers for particular business objects.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
"List Partitioning" where the table is partitioned by
|
The table is partitioned along a <quote>range</quote> defined
|
||||||
explicitly listing which values relate to each partition.
|
by a single column or set of columns, with no overlap between
|
||||||
</para>
|
partitions. Examples might be a date range or a range of
|
||||||
</listitem>
|
identifiers for particular business objects.
|
||||||
</itemizedlist>
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term>List Partitioning</term>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The table is partitioned by explicitly listing which values
|
||||||
|
relate to each partition.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
|
||||||
Hash partitioning is not currently supported.
|
Hash partitioning is not currently supported.
|
||||||
</para>
|
</para>
|
||||||
@ -1471,8 +1481,7 @@ SELECT * from cities*;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
We will refer to the child tables as partitions, though they
|
We will refer to the child tables as partitions, though they
|
||||||
are in every way just normal <productname>PostgreSQL</>
|
are in every way normal <productname>PostgreSQL</> tables.
|
||||||
tables.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -1485,15 +1494,16 @@ SELECT * from cities*;
|
|||||||
for constraint exclusion. Simple examples would be:
|
for constraint exclusion. Simple examples would be:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CHECK ( x = 1 )
|
CHECK ( x = 1 )
|
||||||
CHECK ( county IN ('Oxfordshire','Buckinghamshire','Warwickshire'))
|
CHECK ( county IN ( 'Oxfordshire','Buckinghamshire','Warwickshire' ))
|
||||||
CHECK ( outletID BETWEEN 1 AND 99 )
|
CHECK ( outletID BETWEEN 1 AND 99 )
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
These can be linked together with boolean operators AND and OR to
|
These can be linked together with the boolean operators
|
||||||
form complex constraints. Note that there is no difference in syntax
|
<literal>AND</literal> and <literal>OR</literal> to form
|
||||||
between Range and List Partitioning mechanisms; those terms are
|
complex constraints. Note that there is no difference in
|
||||||
descriptive only. Ensure that the set of values in each child table
|
syntax between range and list partitioning; those terms are
|
||||||
do not overlap.
|
descriptive only. Ensure that the set of values in each child
|
||||||
|
table do not overlap.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -1712,19 +1722,22 @@ DO INSTEAD
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
For some datatypes you must explicitly coerce the constant values
|
For some datatypes you must explicitly coerce the constant
|
||||||
into the datatype of the column. The following constraint will
|
values into the datatype of the column. The following constraint
|
||||||
work if x is an INTEGER datatype, but not if x is BIGINT datatype.
|
will work if <varname>x</varname> is an <type>integer</type>
|
||||||
|
datatype, but not if <varname>x</varname> is a
|
||||||
|
<type>bigint</type>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CHECK ( x = 1 )
|
CHECK ( x = 1 )
|
||||||
</programlisting>
|
</programlisting>
|
||||||
For BIGINT we must use a constraint like:
|
For <type>bigint</type> we must use a constraint like:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CHECK ( x = 1::bigint )
|
CHECK ( x = 1::bigint )
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The issue is not restricted to BIGINT datatypes but can occur whenever
|
The problem is not limited to the <type>bigint</type> datatype
|
||||||
the default datatype of the constant does not match the datatype of
|
— it can occur whenever the default datatype of the
|
||||||
the column to which it is being compared.
|
constant does not match the datatype of the column to which it
|
||||||
|
is being compared.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -2312,8 +2325,8 @@ REVOKE ALL ON accounts FROM PUBLIC;
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To create a schema, use the command <literal>CREATE
|
To create a schema, use the command <command>CREATE
|
||||||
SCHEMA</literal>. Give the schema a name of your choice. For
|
SCHEMA</command>. Give the schema a name of your choice. For
|
||||||
example:
|
example:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE SCHEMA myschema;
|
CREATE SCHEMA myschema;
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_role.sgml,v 1.3 2005/08/14 23:35:38 tgl Exp $
|
$PostgreSQL: pgsql/doc/src/sgml/ref/create_role.sgml,v 1.4 2005/11/03 00:51:43 neilc Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -112,7 +112,7 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
These clauses determine whether a role will be permitted to
|
These clauses determine whether a role will be permitted to
|
||||||
create new roles (that is, execute <literal>CREATE ROLE</literal>).
|
create new roles (that is, execute <command>CREATE ROLE</command>).
|
||||||
A role with <literal>CREATEROLE</literal> privilege can also alter
|
A role with <literal>CREATEROLE</literal> privilege can also alter
|
||||||
and drop other roles.
|
and drop other roles.
|
||||||
If not specified,
|
If not specified,
|
||||||
@ -374,7 +374,7 @@ CREATE ROLE jonathan LOGIN;
|
|||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE USER davide WITH PASSWORD 'jw8s0F4';
|
CREATE USER davide WITH PASSWORD 'jw8s0F4';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
(<literal>CREATE USER</> is the same as <literal>CREATE ROLE</> except
|
(<command>CREATE USER</> is the same as <command>CREATE ROLE</> except
|
||||||
that it implies <literal>LOGIN</>.)
|
that it implies <literal>LOGIN</>.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user