1999-07-22 17:09:15 +02:00
|
|
|
<!--
|
2010-09-20 22:08:53 +02:00
|
|
|
doc/src/sgml/ref/delete.sgml
|
2001-12-08 04:24:40 +01:00
|
|
|
PostgreSQL documentation
|
1999-07-22 17:09:15 +02:00
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-delete">
|
2014-02-24 03:25:35 +01:00
|
|
|
<indexterm zone="sql-delete">
|
|
|
|
<primary>DELETE</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<refmeta>
|
2010-04-03 09:23:02 +02:00
|
|
|
<refentrytitle>DELETE</refentrytitle>
|
2008-11-14 11:22:48 +01:00
|
|
|
<manvolnum>7</manvolnum>
|
1999-07-06 19:16:42 +02:00
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refnamediv>
|
|
|
|
<refname>DELETE</refname>
|
|
|
|
<refpurpose>delete rows of a table</refpurpose>
|
1998-12-29 03:24:47 +01:00
|
|
|
</refnamediv>
|
2003-04-27 01:56:51 +02:00
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<refsynopsisdiv>
|
2003-04-27 01:56:51 +02:00
|
|
|
<synopsis>
|
2010-10-16 01:53:59 +02:00
|
|
|
[ WITH [ RECURSIVE ] <replaceable class="parameter">with_query</replaceable> [, ...] ]
|
2017-10-09 04:00:57 +02:00
|
|
|
DELETE FROM [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ] [ [ AS ] <replaceable class="parameter">alias</replaceable> ]
|
2020-03-31 22:31:44 +02:00
|
|
|
[ USING <replaceable class="parameter">from_item</replaceable> [, ...] ]
|
2017-10-09 04:00:57 +02:00
|
|
|
[ WHERE <replaceable class="parameter">condition</replaceable> | WHERE CURRENT OF <replaceable class="parameter">cursor_name</replaceable> ]
|
2008-02-15 23:17:06 +01:00
|
|
|
[ RETURNING * | <replaceable class="parameter">output_expression</replaceable> [ [ AS ] <replaceable class="parameter">output_name</replaceable> ] [, ...] ]
|
2003-04-27 01:56:51 +02:00
|
|
|
</synopsis>
|
1999-07-06 19:16:42 +02:00
|
|
|
</refsynopsisdiv>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
1999-07-22 17:09:15 +02:00
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<para>
|
2003-04-27 01:56:51 +02:00
|
|
|
<command>DELETE</command> deletes rows that satisfy the
|
|
|
|
<literal>WHERE</literal> clause from the specified table. If the
|
|
|
|
<literal>WHERE</literal> clause is absent, the effect is to delete
|
|
|
|
all rows in the table. The result is a valid, but empty table.
|
1999-07-06 19:16:42 +02:00
|
|
|
</para>
|
1999-07-22 17:09:15 +02:00
|
|
|
|
1999-10-01 17:24:46 +02:00
|
|
|
<tip>
|
|
|
|
<para>
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
<link linkend="sql-truncate"><command>TRUNCATE</command></link> provides a
|
1999-10-01 17:24:46 +02:00
|
|
|
faster mechanism to remove all rows from a table.
|
|
|
|
</para>
|
|
|
|
</tip>
|
1999-07-22 17:09:15 +02:00
|
|
|
|
2005-04-07 03:51:41 +02:00
|
|
|
<para>
|
|
|
|
There are two ways to delete rows in a table using information
|
|
|
|
contained in other tables in the database: using sub-selects, or
|
|
|
|
specifying additional tables in the <literal>USING</literal> clause.
|
|
|
|
Which technique is more appropriate depends on the specific
|
|
|
|
circumstances.
|
|
|
|
</para>
|
|
|
|
|
2006-08-12 04:52:06 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The optional <literal>RETURNING</literal> clause causes <command>DELETE</command>
|
2006-08-12 04:52:06 +02:00
|
|
|
to compute and return value(s) based on each row actually deleted.
|
|
|
|
Any expression using the table's columns, and/or columns of other
|
|
|
|
tables mentioned in <literal>USING</literal>, can be computed.
|
2017-10-09 03:44:17 +02:00
|
|
|
The syntax of the <literal>RETURNING</literal> list is identical to that of the
|
|
|
|
output list of <command>SELECT</command>.
|
2006-08-12 04:52:06 +02:00
|
|
|
</para>
|
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<para>
|
2003-04-27 01:56:51 +02:00
|
|
|
You must have the <literal>DELETE</literal> privilege on the table
|
|
|
|
to delete from it, as well as the <literal>SELECT</literal>
|
2005-04-07 03:51:41 +02:00
|
|
|
privilege for any table in the <literal>USING</literal> clause or
|
|
|
|
whose values are read in the <replaceable
|
2003-04-27 01:56:51 +02:00
|
|
|
class="parameter">condition</replaceable>.
|
1999-07-06 19:16:42 +02:00
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
<variablelist>
|
2010-10-16 01:53:59 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">with_query</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <literal>WITH</literal> clause allows you to specify one or more
|
2017-10-09 03:44:17 +02:00
|
|
|
subqueries that can be referenced by name in the <command>DELETE</command>
|
2017-11-23 15:39:47 +01:00
|
|
|
query. See <xref linkend="queries-with"/> and <xref linkend="sql-select"/>
|
2010-10-16 01:53:59 +02:00
|
|
|
for details.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<varlistentry>
|
2012-06-22 00:06:14 +02:00
|
|
|
<term><replaceable class="parameter">table_name</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2012-09-17 20:59:31 +02:00
|
|
|
The name (optionally schema-qualified) of the table to delete rows
|
2017-10-09 03:44:17 +02:00
|
|
|
from. If <literal>ONLY</literal> is specified before the table name,
|
2012-09-17 20:59:31 +02:00
|
|
|
matching rows are deleted from the named table only. If
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>ONLY</literal> is not specified, matching rows are also deleted
|
2012-09-17 20:59:31 +02:00
|
|
|
from any tables inheriting from the named table. Optionally,
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>*</literal> can be specified after the table name to explicitly
|
2012-09-17 20:59:31 +02:00
|
|
|
indicate that descendant tables are included.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2006-01-22 06:20:35 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">alias</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A substitute name for the target table. When an alias is
|
|
|
|
provided, it completely hides the actual name of the table. For
|
2017-10-09 03:44:17 +02:00
|
|
|
example, given <literal>DELETE FROM foo AS f</literal>, the remainder
|
2006-01-22 06:20:35 +01:00
|
|
|
of the <command>DELETE</command> statement must refer to this
|
2017-10-09 03:44:17 +02:00
|
|
|
table as <literal>f</literal> not <literal>foo</literal>.
|
2006-01-22 06:20:35 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2005-04-07 03:51:41 +02:00
|
|
|
<varlistentry>
|
2020-03-31 22:31:44 +02:00
|
|
|
<term><replaceable class="parameter">from_item</replaceable></term>
|
2005-04-07 03:51:41 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2020-03-31 22:31:44 +02:00
|
|
|
A table expression allowing columns from other tables to appear
|
|
|
|
in the <literal>WHERE</literal> condition. This uses the same
|
Doc: fix "Unresolved ID reference" warnings, clean up man page cross-refs.
Use xreflabel attributes instead of endterm attributes to control the
appearance of links to subsections of SQL command reference pages.
This is simpler, it matches what we do elsewhere (e.g. for GUC variables),
and it doesn't draw "Unresolved ID reference" warnings from the PDF
toolchain.
Fix some places where the text was absolutely dependent on an <xref>
rendering exactly so, by using a <link> around the required text
instead. At least one of those spots had already been turned into
bad grammar by subsequent changes, and the whole idea is just too
fragile for my taste. <xref> does NOT have fixed output, don't write
as if it does.
Consistently include a page-level link in cross-man-page references,
because otherwise they are useless/nonsensical in man-page output.
Likewise, be consistent about mentioning "below" or "above" in same-page
references; we were doing that in about 90% of the cases, but now it's
100%.
Also get rid of another nonfunctional-in-PDF idea, of making
cross-references to functions by sticking ID tags on <row> constructs.
We can put the IDs on <indexterm>s instead --- which is probably not any
more sensible in abstract terms, but it works where the other doesn't.
(There is talk of attaching cross-reference IDs to most or all of
the docs' function descriptions, but for now I just fixed the two
that exist.)
Discussion: https://postgr.es/m/14480.1589154358@sss.pgh.pa.us
2020-05-11 20:15:49 +02:00
|
|
|
syntax as the <link linkend="sql-from"><literal>FROM</literal></link>
|
|
|
|
clause of a <command>SELECT</command> statement; for example, an alias
|
2020-03-31 22:31:44 +02:00
|
|
|
for the table name can be specified. Do not repeat the target
|
|
|
|
table as a <replaceable class="parameter">from_item</replaceable>
|
|
|
|
unless you wish to set up a self-join (in which case it must appear
|
|
|
|
with an alias in the <replaceable>from_item</replaceable>).
|
2005-04-07 03:51:41 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">condition</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2007-06-11 03:16:30 +02:00
|
|
|
An expression that returns a value of type <type>boolean</type>.
|
2017-10-09 03:44:17 +02:00
|
|
|
Only rows for which this expression returns <literal>true</literal>
|
2007-06-11 03:16:30 +02:00
|
|
|
will be deleted.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">cursor_name</replaceable></term>
|
2007-06-11 03:16:30 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The name of the cursor to use in a <literal>WHERE CURRENT OF</literal>
|
2007-06-11 03:16:30 +02:00
|
|
|
condition. The row to be deleted is the one most recently fetched
|
2008-11-16 18:34:28 +01:00
|
|
|
from this cursor. The cursor must be a non-grouping
|
2017-10-09 03:44:17 +02:00
|
|
|
query on the <command>DELETE</command>'s target table.
|
|
|
|
Note that <literal>WHERE CURRENT OF</literal> cannot be
|
2008-11-16 18:34:28 +01:00
|
|
|
specified together with a Boolean condition. See
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sql-declare"/>
|
2008-11-16 18:34:28 +01:00
|
|
|
for more information about using cursors with
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>WHERE CURRENT OF</literal>.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2006-08-12 04:52:06 +02:00
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">output_expression</replaceable></term>
|
2006-08-12 04:52:06 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
An expression to be computed and returned by the <command>DELETE</command>
|
Update reference documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 00:26:05 +01:00
|
|
|
command after each row is deleted. The expression can use any
|
2017-10-09 04:00:57 +02:00
|
|
|
column names of the table named by <replaceable class="parameter">table_name</replaceable>
|
2017-10-09 03:44:17 +02:00
|
|
|
or table(s) listed in <literal>USING</literal>.
|
|
|
|
Write <literal>*</literal> to return all columns.
|
2006-08-12 04:52:06 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">output_name</replaceable></term>
|
2006-08-12 04:52:06 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A name to use for a returned column.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2003-04-27 01:56:51 +02:00
|
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
2003-09-12 02:12:47 +02:00
|
|
|
<title>Outputs</title>
|
2003-04-27 01:56:51 +02:00
|
|
|
|
2003-09-12 02:12:47 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
On successful completion, a <command>DELETE</command> command returns a command
|
2003-09-12 02:12:47 +02:00
|
|
|
tag of the form
|
|
|
|
<screen>
|
|
|
|
DELETE <replaceable class="parameter">count</replaceable>
|
|
|
|
</screen>
|
|
|
|
The <replaceable class="parameter">count</replaceable> is the number
|
2011-10-10 18:53:04 +02:00
|
|
|
of rows deleted. Note that the number may be less than the number of
|
|
|
|
rows that matched the <replaceable
|
|
|
|
class="parameter">condition</replaceable> when deletes were
|
2017-10-09 03:44:17 +02:00
|
|
|
suppressed by a <literal>BEFORE DELETE</literal> trigger. If <replaceable
|
2011-10-10 18:53:04 +02:00
|
|
|
class="parameter">count</replaceable> is 0, no rows were deleted by
|
|
|
|
the query (this is not considered an error).
|
2003-09-12 02:12:47 +02:00
|
|
|
</para>
|
2006-08-12 04:52:06 +02:00
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
If the <command>DELETE</command> command contains a <literal>RETURNING</literal>
|
|
|
|
clause, the result will be similar to that of a <command>SELECT</command>
|
2006-08-12 04:52:06 +02:00
|
|
|
statement containing the columns and values defined in the
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>RETURNING</literal> list, computed over the row(s) deleted by the
|
2006-08-12 04:52:06 +02:00
|
|
|
command.
|
|
|
|
</para>
|
2003-04-27 01:56:51 +02:00
|
|
|
</refsect1>
|
|
|
|
|
2005-01-09 06:57:45 +01:00
|
|
|
<refsect1>
|
|
|
|
<title>Notes</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<productname>PostgreSQL</productname> lets you reference columns of
|
2017-10-09 03:44:17 +02:00
|
|
|
other tables in the <literal>WHERE</literal> condition by specifying the
|
2005-04-07 03:51:41 +02:00
|
|
|
other tables in the <literal>USING</literal> clause. For example,
|
2007-02-01 01:28:19 +01:00
|
|
|
to delete all films produced by a given producer, one can do:
|
2005-01-09 06:57:45 +01:00
|
|
|
<programlisting>
|
2005-04-07 03:51:41 +02:00
|
|
|
DELETE FROM films USING producers
|
2005-01-09 06:57:45 +01:00
|
|
|
WHERE producer_id = producers.id AND producers.name = 'foo';
|
|
|
|
</programlisting>
|
2017-10-09 03:44:17 +02:00
|
|
|
What is essentially happening here is a join between <structname>films</structname>
|
|
|
|
and <structname>producers</structname>, with all successfully joined
|
|
|
|
<structname>films</structname> rows being marked for deletion.
|
2007-02-01 01:28:19 +01:00
|
|
|
This syntax is not standard. A more standard way to do it is:
|
2005-01-09 06:57:45 +01:00
|
|
|
<programlisting>
|
|
|
|
DELETE FROM films
|
|
|
|
WHERE producer_id IN (SELECT id FROM producers WHERE name = 'foo');
|
|
|
|
</programlisting>
|
|
|
|
In some cases the join style is easier to write or faster to
|
2005-04-07 03:51:41 +02:00
|
|
|
execute than the sub-select style.
|
|
|
|
</para>
|
2005-01-09 06:57:45 +01:00
|
|
|
</refsect1>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<para>
|
2003-04-27 01:56:51 +02:00
|
|
|
Delete all films but musicals:
|
2000-03-26 20:32:30 +02:00
|
|
|
<programlisting>
|
1999-07-06 19:16:42 +02:00
|
|
|
DELETE FROM films WHERE kind <> 'Musical';
|
2000-03-26 20:32:30 +02:00
|
|
|
</programlisting>
|
1999-07-06 19:16:42 +02:00
|
|
|
</para>
|
|
|
|
|
1998-09-01 17:53:09 +02:00
|
|
|
<para>
|
1998-09-22 17:48:03 +02:00
|
|
|
Clear the table <literal>films</literal>:
|
2000-03-26 20:32:30 +02:00
|
|
|
<programlisting>
|
1998-09-22 17:48:03 +02:00
|
|
|
DELETE FROM films;
|
2008-11-16 18:34:28 +01:00
|
|
|
</programlisting>
|
2006-08-12 04:52:06 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Delete completed tasks, returning full details of the deleted rows:
|
|
|
|
<programlisting>
|
|
|
|
DELETE FROM tasks WHERE status = 'DONE' RETURNING *;
|
2008-11-16 18:34:28 +01:00
|
|
|
</programlisting>
|
2007-06-11 03:16:30 +02:00
|
|
|
</para>
|
|
|
|
|
2024-04-07 22:26:47 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Delete the row of <structname>tasks</structname> on which the cursor
|
|
|
|
<literal>c_tasks</literal> is currently positioned:
|
2007-06-11 03:16:30 +02:00
|
|
|
<programlisting>
|
|
|
|
DELETE FROM tasks WHERE CURRENT OF c_tasks;
|
2024-04-07 22:26:47 +02:00
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
While there is no <literal>LIMIT</literal> clause
|
|
|
|
for <command>DELETE</command>, it is possible to get a similar effect
|
|
|
|
using the same method described in <link linkend="update-limit">the
|
|
|
|
documentation of <command>UPDATE</command></link>:
|
|
|
|
<programlisting>
|
|
|
|
WITH delete_batch AS (
|
|
|
|
SELECT l.ctid FROM user_logs AS l
|
|
|
|
WHERE l.status = 'archived'
|
|
|
|
ORDER BY l.creation_date
|
|
|
|
FOR UPDATE
|
|
|
|
LIMIT 10000
|
|
|
|
)
|
|
|
|
DELETE FROM user_logs AS dl
|
|
|
|
USING delete_batch AS del
|
|
|
|
WHERE dl.ctid = del.ctid;
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
1999-07-06 19:16:42 +02:00
|
|
|
</refsect1>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Compatibility</title>
|
|
|
|
|
|
|
|
<para>
|
2006-08-12 04:52:06 +02:00
|
|
|
This command conforms to the <acronym>SQL</acronym> standard, except
|
2017-10-09 03:44:17 +02:00
|
|
|
that the <literal>USING</literal> and <literal>RETURNING</literal> clauses
|
2010-10-16 01:53:59 +02:00
|
|
|
are <productname>PostgreSQL</productname> extensions, as is the ability
|
2017-10-09 03:44:17 +02:00
|
|
|
to use <literal>WITH</literal> with <command>DELETE</command>.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
1998-09-01 17:53:09 +02:00
|
|
|
</refsect1>
|
2017-03-18 19:25:41 +01:00
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
2017-11-23 15:39:47 +01:00
|
|
|
<member><xref linkend="sql-truncate"/></member>
|
2017-03-18 19:25:41 +01:00
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
1999-07-06 19:16:42 +02:00
|
|
|
</refentry>
|