mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

A bit of minor copy-editing.

Browse Source
This commit is contained in:
Tom Lane 2005-10-23 19:29:49 +00:00
parent 55337e40b3
commit 7d3ab8ac55
2 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/src/sgml/ddl.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.44 2005/08/13 01:55:41 momjian Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.45 2005/10/23 19:29:49 tgl Exp $ -->
<chapter id="ddl"> <chapter id="ddl">
<title>Data Definition</title> <title>Data Definition</title>
@ -240,7 +240,7 @@ CREATE TABLE products (
in a table. For many applications, however, the constraint they in a table. For many applications, however, the constraint they
provide is too coarse. For example, a column containing a product provide is too coarse. For example, a column containing a product
price should probably only accept positive values. But there is no price should probably only accept positive values. But there is no
data type that accepts only positive numbers. Another issue is standard data type that accepts only positive numbers. Another issue is
that you might want to constrain column data with respect to other that you might want to constrain column data with respect to other
columns or rows. For example, in a table containing product columns or rows. For example, in a table containing product
information, there should only be one row for each product number. information, there should only be one row for each product number.
@ -431,7 +431,7 @@ CREATE TABLE products (
IS NOT NULL)</literal>, but in IS NOT NULL)</literal>, but in
<productname>PostgreSQL</productname> creating an explicit <productname>PostgreSQL</productname> creating an explicit
not-null constraint is more efficient. The drawback is that you not-null constraint is more efficient. The drawback is that you
cannot give explicit names to not-null constraints created that cannot give explicit names to not-null constraints created this
way. way.
</para> </para>
@ -551,7 +551,7 @@ CREATE TABLE products (
columns included in the constraint are equal. columns included in the constraint are equal.
However, null values are not considered equal in this However, null values are not considered equal in this
comparison. That means even in the presence of a comparison. That means even in the presence of a
unique constraint it is possible to store an unlimited number of unique constraint it is possible to store duplicate
rows that contain a null value in at least one of the constrained rows that contain a null value in at least one of the constrained
columns. This behavior conforms to the SQL standard, but we have columns. This behavior conforms to the SQL standard, but we have
heard that other SQL databases may not follow this rule. So be heard that other SQL databases may not follow this rule. So be

18
doc/src/sgml/syntax.sgml
View File

@ -1,5 +1,5 @@
<!-- <!--
$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.103 2005/08/14 22:19:50 petere Exp $ $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.104 2005/10/23 19:29:49 tgl Exp $
--> -->
<chapter id="sql-syntax"> <chapter id="sql-syntax">
@ -260,7 +260,7 @@ UPDATE "my_table" SET "a" = 5;
<literal>\n</literal> is a newline, <literal>\r</literal> is a <literal>\n</literal> is a newline, <literal>\r</literal> is a
carriage return, <literal>\t</literal> is a tab. Also supported is carriage return, <literal>\t</literal> is a tab. Also supported is
<literal>\<replaceable>digits</replaceable></literal>, where <literal>\<replaceable>digits</replaceable></literal>, where
<replaceable>ddd</replaceable> represents an octal byte value, and <replaceable>digits</replaceable> represents an octal byte value, and
<literal>\x<replaceable>hexdigits</replaceable></literal>, where <literal>\x<replaceable>hexdigits</replaceable></literal>, where
<replaceable>hexdigits</replaceable> represents a hexadecimal byte value. <replaceable>hexdigits</replaceable> represents a hexadecimal byte value.
(It is your responsibility that the byte sequences you create are (It is your responsibility that the byte sequences you create are
@ -544,6 +544,16 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
is that it does not work for array types; use <literal>::</literal> is that it does not work for array types; use <literal>::</literal>
or <literal>CAST()</literal> to specify the type of an array constant. or <literal>CAST()</literal> to specify the type of an array constant.
</para> </para>
<para>
The <literal>CAST()</> syntax conforms to SQL. The
<literal><replaceable>type</replaceable> '<replaceable>string</replaceable>'</literal>
syntax is a generalization of the standard: SQL specifies this syntax only
for a few datatypes, but <productname>PostgreSQL</productname> allows it
for all types. The syntax with
<literal>::</literal> is historical <productname>PostgreSQL</productname>
usage, as is the function-call syntax.
</para>
</sect3> </sect3>
</sect2> </sect2>
@ -1105,8 +1115,8 @@ CREATE FUNCTION dept(text) RETURNS dept
LANGUAGE SQL; LANGUAGE SQL;
</programlisting> </programlisting>
Here the <literal>$1</literal> will be replaced by the first Here the <literal>$1</literal> references the value of the first
function argument when the function is invoked. function argument whenever the function is invoked.
</para> </para>
</sect2> </sect2>