2002-08-27 06:55:12 +02:00
|
|
|
<!--
|
2010-09-20 22:08:53 +02:00
|
|
|
doc/src/sgml/ref/prepare.sgml
|
2002-08-27 06:55:12 +02:00
|
|
|
PostgreSQL documentation
|
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-prepare">
|
2014-02-24 03:25:35 +01:00
|
|
|
<indexterm zone="sql-prepare">
|
|
|
|
<primary>PREPARE</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm zone="sql-prepare">
|
|
|
|
<primary>prepared statements</primary>
|
|
|
|
<secondary>creating</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
<refmeta>
|
2010-04-03 09:23:02 +02:00
|
|
|
<refentrytitle>PREPARE</refentrytitle>
|
2008-11-14 11:22:48 +01:00
|
|
|
<manvolnum>7</manvolnum>
|
2002-08-27 06:55:12 +02:00
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
2003-04-27 01:56:51 +02:00
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
<refnamediv>
|
2003-04-27 01:56:51 +02:00
|
|
|
<refname>PREPARE</refname>
|
|
|
|
<refpurpose>prepare a statement for execution</refpurpose>
|
2002-08-27 06:55:12 +02:00
|
|
|
</refnamediv>
|
2003-04-27 01:56:51 +02:00
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
<refsynopsisdiv>
|
2003-04-27 01:56:51 +02:00
|
|
|
<synopsis>
|
2017-10-09 04:00:57 +02:00
|
|
|
PREPARE <replaceable class="parameter">name</replaceable> [ ( <replaceable class="parameter">data_type</replaceable> [, ...] ) ] AS <replaceable class="parameter">statement</replaceable>
|
2003-04-27 01:56:51 +02:00
|
|
|
</synopsis>
|
2002-08-27 06:55:12 +02:00
|
|
|
</refsynopsisdiv>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
<para>
|
2003-04-27 01:56:51 +02:00
|
|
|
<command>PREPARE</command> creates a prepared statement. A prepared
|
|
|
|
statement is a server-side object that can be used to optimize
|
2002-08-27 06:55:12 +02:00
|
|
|
performance. When the <command>PREPARE</command> statement is
|
2011-09-16 06:42:53 +02:00
|
|
|
executed, the specified statement is parsed, analyzed, and rewritten.
|
|
|
|
When an <command>EXECUTE</command> command is subsequently
|
|
|
|
issued, the prepared statement is planned and executed. This division
|
|
|
|
of labor avoids repetitive parse analysis work, while allowing
|
|
|
|
the execution plan to depend on the specific parameter values supplied.
|
2002-08-27 06:55:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-04-27 01:56:51 +02:00
|
|
|
Prepared statements can take parameters: values that are
|
2006-01-15 23:18:47 +01:00
|
|
|
substituted into the statement when it is executed. When creating
|
|
|
|
the prepared statement, refer to parameters by position, using
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>$1</literal>, <literal>$2</literal>, etc. A corresponding list of
|
2006-01-15 23:18:47 +01:00
|
|
|
parameter data types can optionally be specified. When a
|
|
|
|
parameter's data type is not specified or is declared as
|
|
|
|
<literal>unknown</literal>, the type is inferred from the context
|
2018-08-09 16:13:15 +02:00
|
|
|
in which the parameter is first referenced (if possible). When executing the
|
2006-01-15 23:18:47 +01:00
|
|
|
statement, specify the actual values for these parameters in the
|
|
|
|
<command>EXECUTE</command> statement. Refer to <xref
|
2017-11-23 15:39:47 +01:00
|
|
|
linkend="sql-execute"/> for more
|
2003-04-27 01:56:51 +02:00
|
|
|
information about that.
|
2002-08-27 06:55:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-12-14 01:55:46 +01:00
|
|
|
Prepared statements only last for the duration of the current
|
2003-12-01 23:08:02 +01:00
|
|
|
database session. When the session ends, the prepared statement is
|
2010-11-23 21:27:50 +01:00
|
|
|
forgotten, so it must be recreated before being used again. This
|
2004-04-20 01:36:48 +02:00
|
|
|
also means that a single prepared statement cannot be used by
|
|
|
|
multiple simultaneous database clients; however, each client can create
|
2011-09-16 06:42:53 +02:00
|
|
|
their own prepared statement to use. Prepared statements can be
|
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
|
|
|
manually cleaned up using the <link linkend="sql-deallocate"><command>DEALLOCATE</command></link> command.
|
2002-08-27 06:55:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2016-06-14 22:11:46 +02:00
|
|
|
Prepared statements potentially have the largest performance advantage
|
|
|
|
when a single session is being used to execute a large number of similar
|
2003-04-27 01:56:51 +02:00
|
|
|
statements. The performance difference will be particularly
|
2020-09-01 00:33:37 +02:00
|
|
|
significant if the statements are complex to plan or rewrite, e.g.,
|
2016-06-14 22:11:46 +02:00
|
|
|
if the query involves a join of many tables or requires
|
2003-04-27 01:56:51 +02:00
|
|
|
the application of several rules. If the statement is relatively simple
|
2002-08-27 06:55:12 +02:00
|
|
|
to plan and rewrite but relatively expensive to execute, the
|
2003-04-27 01:56:51 +02:00
|
|
|
performance advantage of prepared statements will be less noticeable.
|
2002-08-27 06:55:12 +02:00
|
|
|
</para>
|
2003-04-27 01:56:51 +02:00
|
|
|
</refsect1>
|
2002-08-27 06:55:12 +02:00
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">name</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
An arbitrary name given to this particular prepared
|
|
|
|
statement. It must be unique within a single session and is
|
|
|
|
subsequently used to execute or deallocate a previously prepared
|
|
|
|
statement.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">data_type</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2006-01-15 23:18:47 +01:00
|
|
|
The data type of a parameter to the prepared statement. If the
|
|
|
|
data type of a particular parameter is unspecified or is
|
|
|
|
specified as <literal>unknown</literal>, it will be inferred
|
2018-08-09 16:13:15 +02:00
|
|
|
from the context in which the parameter is first referenced. To refer to the
|
2006-01-15 23:18:47 +01:00
|
|
|
parameters in the prepared statement itself, use
|
2003-04-27 01:56:51 +02:00
|
|
|
<literal>$1</literal>, <literal>$2</literal>, etc.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">statement</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Any <command>SELECT</command>, <command>INSERT</command>, <command>UPDATE</command>,
|
|
|
|
<command>DELETE</command>, or <command>VALUES</command> statement.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
2002-08-27 06:55:12 +02:00
|
|
|
</refsect1>
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refsect1 id="sql-prepare-notes">
|
2003-04-27 01:56:51 +02:00
|
|
|
<title>Notes</title>
|
|
|
|
|
|
|
|
<para>
|
2019-09-30 20:31:12 +02:00
|
|
|
A prepared statement can be executed with either a <firstterm>generic
|
|
|
|
plan</firstterm> or a <firstterm>custom plan</firstterm>. A generic
|
|
|
|
plan is the same across all executions, while a custom plan is generated
|
|
|
|
for a specific execution using the parameter values given in that call.
|
|
|
|
Use of a generic plan avoids planning overhead, but in some situations
|
|
|
|
a custom plan will be much more efficient to execute because the planner
|
|
|
|
can make use of knowledge of the parameter values. (Of course, if the
|
|
|
|
prepared statement has no parameters, then this is moot and a generic
|
|
|
|
plan is always used.)
|
2016-06-14 22:11:46 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2019-09-30 20:31:12 +02:00
|
|
|
By default (that is, when <xref linkend="guc-plan-cache_mode"/> is set
|
|
|
|
to <literal>auto</literal>), the server will automatically choose
|
|
|
|
whether to use a generic or custom plan for a prepared statement that
|
|
|
|
has parameters. The current rule for this is that the first five
|
|
|
|
executions are done with custom plans and the average estimated cost of
|
|
|
|
those plans is calculated. Then a generic plan is created and its
|
|
|
|
estimated cost is compared to the average custom-plan cost. Subsequent
|
|
|
|
executions use the generic plan if its cost is not so much higher than
|
|
|
|
the average custom-plan cost as to make repeated replanning seem
|
|
|
|
preferable.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This heuristic can be overridden, forcing the server to use either
|
|
|
|
generic or custom plans, by setting <varname>plan_cache_mode</varname>
|
|
|
|
to <literal>force_generic_plan</literal>
|
|
|
|
or <literal>force_custom_plan</literal> respectively.
|
|
|
|
This setting is primarily useful if the generic plan's cost estimate
|
|
|
|
is badly off for some reason, allowing it to be chosen even though
|
|
|
|
its actual cost is much more than that of a custom plan.
|
2011-09-16 06:42:53 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To examine the query plan <productname>PostgreSQL</productname> is using
|
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
|
|
|
for a prepared statement, use <link linkend="sql-explain"><command>EXPLAIN</command></link>, for example
|
2019-09-30 20:31:12 +02:00
|
|
|
<programlisting>
|
2019-10-16 06:09:52 +02:00
|
|
|
EXPLAIN EXECUTE <replaceable>name</replaceable>(<replaceable>parameter_values</replaceable>);
|
2019-09-30 20:31:12 +02:00
|
|
|
</programlisting>
|
2011-09-16 06:42:53 +02:00
|
|
|
If a generic plan is in use, it will contain parameter symbols
|
2019-09-30 20:31:12 +02:00
|
|
|
<literal>$<replaceable>n</replaceable></literal>, while a custom plan
|
|
|
|
will have the supplied parameter values substituted into it.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For more information on query planning and the statistics collected
|
|
|
|
by <productname>PostgreSQL</productname> for that purpose, see
|
2017-11-23 15:39:47 +01:00
|
|
|
the <xref linkend="sql-analyze"/>
|
2003-04-27 01:56:51 +02:00
|
|
|
documentation.
|
|
|
|
</para>
|
2006-01-08 08:00:27 +01:00
|
|
|
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
<para>
|
|
|
|
Although the main point of a prepared statement is to avoid repeated parse
|
2017-10-09 03:44:17 +02:00
|
|
|
analysis and planning of the statement, <productname>PostgreSQL</productname> will
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
force re-analysis and re-planning of the statement before using it
|
|
|
|
whenever database objects used in the statement have undergone
|
2020-12-24 09:05:49 +01:00
|
|
|
definitional (DDL) changes or their planner statistics have
|
2020-11-26 08:17:10 +01:00
|
|
|
been updated since the previous use of the prepared
|
2017-11-23 15:39:47 +01:00
|
|
|
statement. Also, if the value of <xref linkend="guc-search-path"/> changes
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
from one use to the next, the statement will be re-parsed using the new
|
2017-10-09 03:44:17 +02:00
|
|
|
<varname>search_path</varname>. (This latter behavior is new as of
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
<productname>PostgreSQL</productname> 9.3.) These rules make use of a
|
|
|
|
prepared statement semantically almost equivalent to re-submitting the
|
|
|
|
same query text over and over, but with a performance benefit if no object
|
|
|
|
definitions are changed, especially if the best plan remains the same
|
|
|
|
across uses. An example of a case where the semantic equivalence is not
|
|
|
|
perfect is that if the statement refers to a table by an unqualified name,
|
|
|
|
and then a new table of the same name is created in a schema appearing
|
2017-10-09 03:44:17 +02:00
|
|
|
earlier in the <varname>search_path</varname>, no automatic re-parse will occur
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
since no object used in the statement changed. However, if some other
|
|
|
|
change forces a re-parse, the new table will be referenced in subsequent
|
|
|
|
uses.
|
|
|
|
</para>
|
|
|
|
|
2006-01-08 08:00:27 +01:00
|
|
|
<para>
|
2011-09-16 06:42:53 +02:00
|
|
|
You can see all prepared statements available in the session by querying the
|
2006-02-26 04:20:46 +01:00
|
|
|
<link linkend="view-pg-prepared-statements"><structname>pg_prepared_statements</structname></link>
|
|
|
|
system view.
|
2006-01-08 08:00:27 +01:00
|
|
|
</para>
|
2003-04-27 01:56:51 +02:00
|
|
|
</refsect1>
|
|
|
|
|
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
|
|
|
<refsect1 id="sql-prepare-examples" xreflabel="Examples">
|
|
|
|
<title>Examples</title>
|
2004-01-26 18:26:31 +01:00
|
|
|
<para>
|
2006-01-15 23:18:47 +01:00
|
|
|
Create a prepared statement for an <command>INSERT</command>
|
|
|
|
statement, and then execute it:
|
2004-01-26 18:26:31 +01:00
|
|
|
<programlisting>
|
2004-10-29 21:40:33 +02:00
|
|
|
PREPARE fooplan (int, text, bool, numeric) AS
|
|
|
|
INSERT INTO foo VALUES($1, $2, $3, $4);
|
|
|
|
EXECUTE fooplan(1, 'Hunter Valley', 't', 200.00);
|
2004-01-26 18:26:31 +01:00
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2006-01-15 23:18:47 +01:00
|
|
|
Create a prepared statement for a <command>SELECT</command>
|
|
|
|
statement, and then execute it:
|
2004-01-26 18:26:31 +01:00
|
|
|
<programlisting>
|
2006-01-15 23:18:47 +01:00
|
|
|
PREPARE usrrptplan (int) AS
|
2004-01-26 18:26:31 +01:00
|
|
|
SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid
|
|
|
|
AND l.date = $2;
|
|
|
|
EXECUTE usrrptplan(1, current_date);
|
|
|
|
</programlisting>
|
2006-01-15 23:18:47 +01:00
|
|
|
|
2019-09-30 20:31:12 +02:00
|
|
|
In this example, the data type of the second parameter is not specified,
|
2017-10-09 03:44:17 +02:00
|
|
|
so it is inferred from the context in which <literal>$2</literal> is used.
|
2004-01-26 18:26:31 +01:00
|
|
|
</para>
|
|
|
|
</refsect1>
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Compatibility</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The SQL standard includes a <command>PREPARE</command> statement,
|
|
|
|
but it is only for use in embedded SQL. This version of the
|
|
|
|
<command>PREPARE</command> statement also uses a somewhat different
|
|
|
|
syntax.
|
|
|
|
</para>
|
2002-08-27 06:55:12 +02:00
|
|
|
</refsect1>
|
2004-09-20 02:04:19 +02:00
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
2017-11-23 15:39:47 +01:00
|
|
|
<member><xref linkend="sql-deallocate"/></member>
|
|
|
|
<member><xref linkend="sql-execute"/></member>
|
2004-09-20 02:04:19 +02:00
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
2002-08-27 06:55:12 +02:00
|
|
|
</refentry>
|