[
MAINHACK
]
Mail Test
BC
Config Scan
HOME
Create...
New File
New Folder
Viewing / Editing File: PREPARE.7
File is not writable. Editing disabled.
'\" t .\" Title: PREPARE .\" Author: The PostgreSQL Global Development Group .\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/> .\" Date: 2017-11-06 .\" Manual: PostgreSQL 9.2.24 Documentation .\" Source: PostgreSQL 9.2.24 .\" Language: English .\" .TH "PREPARE" "7" "2017-11-06" "PostgreSQL 9.2.24" "PostgreSQL 9.2.24 Documentation" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" PREPARE \- prepare a statement for execution .\" PREPARE .\" prepared statements: creating .SH "SYNOPSIS" .sp .nf PREPARE \fIname\fR [ ( \fIdata_type\fR [, \&.\&.\&.] ) ] AS \fIstatement\fR .fi .SH "DESCRIPTION" .PP \fBPREPARE\fR creates a prepared statement\&. A prepared statement is a server\-side object that can be used to optimize performance\&. When the \fBPREPARE\fR statement is executed, the specified statement is parsed, analyzed, and rewritten\&. When an \fBEXECUTE\fR 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\&. .PP Prepared statements can take parameters: values that are substituted into the statement when it is executed\&. When creating the prepared statement, refer to parameters by position, using $1, $2, etc\&. A corresponding list of parameter data types can optionally be specified\&. When a parameter\*(Aqs data type is not specified or is declared as unknown, the type is inferred from the context in which the parameter is used (if possible)\&. When executing the statement, specify the actual values for these parameters in the \fBEXECUTE\fR statement\&. Refer to \fBEXECUTE\fR(7) for more information about that\&. .PP Prepared statements only last for the duration of the current database session\&. When the session ends, the prepared statement is forgotten, so it must be recreated before being used again\&. This also means that a single prepared statement cannot be used by multiple simultaneous database clients; however, each client can create their own prepared statement to use\&. Prepared statements can be manually cleaned up using the \fBDEALLOCATE\fR(7) command\&. .PP Prepared statements have the largest performance advantage when a single session is being used to execute a large number of similar statements\&. The performance difference will be particularly significant if the statements are complex to plan or rewrite, for example, if the query involves a join of many tables or requires the application of several rules\&. If the statement is relatively simple to plan and rewrite but relatively expensive to execute, the performance advantage of prepared statements will be less noticeable\&. .SH "PARAMETERS" .PP \fIname\fR .RS 4 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\&. .RE .PP \fIdata_type\fR .RS 4 The data type of a parameter to the prepared statement\&. If the data type of a particular parameter is unspecified or is specified as unknown, it will be inferred from the context in which the parameter is used\&. To refer to the parameters in the prepared statement itself, use $1, $2, etc\&. .RE .PP \fIstatement\fR .RS 4 Any \fBSELECT\fR, \fBINSERT\fR, \fBUPDATE\fR, \fBDELETE\fR, or \fBVALUES\fR statement\&. .RE .SH "NOTES" .PP If a prepared statement is executed enough times, the server may eventually decide to save and re\-use a generic plan rather than re\-planning each time\&. This will occur immediately if the prepared statement has no parameters; otherwise it occurs only if the generic plan appears to be not much more expensive than a plan that depends on specific parameter values\&. Typically, a generic plan will be selected only if the query\*(Aqs performance is estimated to be fairly insensitive to the specific parameter values supplied\&. .PP To examine the query plan PostgreSQL is using for a prepared statement, use \fBEXPLAIN\fR(7)\&. If a generic plan is in use, it will contain parameter symbols $\fIn\fR, while a custom plan will have the current actual parameter values substituted into it\&. .PP For more information on query planning and the statistics collected by PostgreSQL for that purpose, see the \fBANALYZE\fR(7) documentation\&. .PP You can see all prepared statements available in the session by querying the pg_prepared_statements system view\&. .SH "EXAMPLES" .PP Create a prepared statement for an \fBINSERT\fR statement, and then execute it: .sp .if n \{\ .RS 4 .\} .nf PREPARE fooplan (int, text, bool, numeric) AS INSERT INTO foo VALUES($1, $2, $3, $4); EXECUTE fooplan(1, \*(AqHunter Valley\*(Aq, \*(Aqt\*(Aq, 200\&.00); .fi .if n \{\ .RE .\} .PP Create a prepared statement for a \fBSELECT\fR statement, and then execute it: .sp .if n \{\ .RS 4 .\} .nf PREPARE usrrptplan (int) AS SELECT * FROM users u, logs l WHERE u\&.usrid=$1 AND u\&.usrid=l\&.usrid AND l\&.date = $2; EXECUTE usrrptplan(1, current_date); .fi .if n \{\ .RE .\} .sp Note that the data type of the second parameter is not specified, so it is inferred from the context in which $2 is used\&. .SH "COMPATIBILITY" .PP The SQL standard includes a \fBPREPARE\fR statement, but it is only for use in embedded SQL\&. This version of the \fBPREPARE\fR statement also uses a somewhat different syntax\&. .SH "SEE ALSO" \fBDEALLOCATE\fR(7), \fBEXECUTE\fR(7)
Save Changes
Cancel / Back
Close ×
Server Info
Hostname: server05.hostinghome.co.in
Server IP: 192.168.74.40
PHP Version: 7.4.33
Server Software: Apache
System: Linux server05.hostinghome.co.in 3.10.0-962.3.2.lve1.5.81.el7.x86_64 #1 SMP Wed May 31 10:36:47 UTC 2023 x86_64
HDD Total: 1.95 TB
HDD Free: 691.06 GB
Domains on IP: N/A (Requires external lookup)
System Features
Safe Mode:
Off
disable_functions:
None
allow_url_fopen:
On
allow_url_include:
Off
magic_quotes_gpc:
Off
register_globals:
Off
open_basedir:
None
cURL:
Enabled
ZipArchive:
Disabled
MySQLi:
Enabled
PDO:
Enabled
wget:
Yes
curl (cmd):
Yes
perl:
Yes
python:
Yes
gcc:
Yes
pkexec:
No
git:
Yes
User Info
Username: itsweb
User ID (UID): 1619
Group ID (GID): 1621
Script Owner UID: 1619
Current Dir Owner: N/A