<listitem>

<para>

Allows for mapping between system and database user names. See

principal, such as <literal>username@EXAMPLE.COM</literal> (or, less

commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the

user name used for mapping is

In general, enclose the value in single quotes, doubling any single

quotes within the value. Quotes can usually be omitted if the value

is a simple number or identifier, however.

</para>

</listitem>

<productname>PostgreSQL</productname> provides three SQL

commands to establish configuration defaults.

The already-mentioned <command>ALTER SYSTEM</command> command

functionally equivalent to editing <filename>postgresql.conf</filename>.

In addition, there are two commands that allow setting of defaults

on a per-database or per-role basis:

<literal>\'</literal>. However, use of <literal>\'</literal> creates security risks

because in some client character set encodings, there are multibyte

characters in which the last byte is numerically equivalent to ASCII

SQL-injection attack is possible. This risk can be prevented by

making the server reject queries in which a quote mark appears to be

escaped by a backslash.

<para>

The reason that single quotes must be doubled, as shown

in <xref linkend="datatype-binary-sqlesc"/>, is that this

string-literal parser consumes the outermost single quotes

and reduces any pair of single quotes to one data character.

What the <type>bytea</type> input function sees is just one

<title>Return Value</title>

<para>

the function returns the row(s) produced by the query. To use this

function, you will need to specify the expected set of columns,

as previously discussed for <function>dblink</function>.

</para>

<para>

the function returns a single row with a single text column containing

the command's status string. It is still necessary to specify that

the result will have a single text column in the calling <literal>FROM</literal>

<para>

<function>dblink_build_sql_insert</function> can be useful in doing selective

replication of a local table to a remote database. It selects a row

<command>INSERT</command> command that will duplicate that row, but with

the primary key values replaced by the values in the last argument.

(To make an exact copy of the row, just specify the same values for

<para>

<function>dblink_build_sql_delete</function> can be useful in doing selective

<command>DELETE</command> command that will delete the row with the given

primary key values.

</para>

<para>

<function>dblink_build_sql_update</function> can be useful in doing selective

replication of a local table to a remote database. It selects a row

<command>UPDATE</command> command that will duplicate that row, but with

the primary key values replaced by the values in the last argument.

(To make an exact copy of the row, just specify the same values for

</para>

<para>

the connection, for example:

<programlisting>

EXEC SQL AT <replaceable>connection-name</replaceable> DECLARE <replaceable>statement-name</replaceable> STATEMENT;

EXEC SQL PREPARE <replaceable>statement-name</replaceable> FROM :<replaceable>dyn-string</replaceable>;

</programlisting>

without an AT clause. Note that this option behaves like preprocessor

directives, therefore the link is enabled only in the file.

</para>

variables and vice-versa. However, when creating a statement ecpg does

not know the types of the columns, so that it cannot check if a C array

is input into a corresponding SQL-level array. When processing the

checks if both are arrays.

</para>

parameters to a prepared query are:

</para>

<step><simpara>Create a prepared query (prepared statement)</simpara></step>

<step><simpara>Allocate memory area (as sqlda_t structure) for the input SQLDA.</simpara></step>

<step><simpara>Set (copy) input values in the allocated memory.</simpara></step>

<step><simpara>Open a cursor with specifying the input SQLDA.</simpara></step>

EXEC SQL PREPARE stmt1 FROM :query;

EXEC SQL DECLARE cur1 CURSOR FOR stmt1;

sqlda2 = (sqlda_t *)malloc(sizeof(sqlda_t) + sizeof(sqlvar_t));

memset(sqlda2, 0, sizeof(sqlda_t) + sizeof(sqlvar_t));

sqlda2->sqln = 2; /* a number of input variables */

<title>Description</title>

<para>

SQL statement identifier can be associated with the connection.

When the identifier is used by dynamic SQL statements, the statements

are executed using the associated connection.

<term><replaceable class="parameter">statement_name</replaceable></term>

<listitem>

<para>

</para>

</listitem>

</varlistentry>

and include the global <acronym>PGXS</acronym> makefile.

Here is an example that builds an extension module named

<literal>isbn_issn</literal>, consisting of a shared library containing

(only needed if other modules might need to access the extension functions

without going via SQL), and a documentation text file:

<programlisting>

<returnvalue>json</returnvalue>

</para>

<para>

as <function>to_json</function> except that line feeds will be added

between top-level array elements if the optional boolean parameter is

true.

<returnvalue>json</returnvalue>

</para>

<para>

same as <function>to_json</function> except that line feeds will be

added between top-level elements if the optional boolean parameter is

true.

<itemizedlist spacing="compact">

<listitem>

<para>

</para>

</listitem>

<listitem>

<literal>string</literal>, <literal>number</literal>,

<literal>boolean</literal>, and <literal>null</literal>.

(The <literal>null</literal> result should not be confused

</para>

<para>

<literal>json_typeof('-123.4')</literal>

Currently, temporary table creation is not allowed during read only

transactions, so in some cases existing scripts will not run correctly.

This restriction might be relaxed in a later release. This is

</para>

<para>

<para>

If the index AM wishes to cache data across successive index insertions

in <literal>indexInfo-&gt;ii_Context</literal> and store a pointer to the

data in <literal>indexInfo-&gt;ii_AmCache</literal> (which will be NULL

initially).

<listitem>

<para>

The text of a failed internally-generated command. This could

</para>

</listitem>

</varlistentry>

</indexterm>

<para>

entire result and returns it to the application as a single

<structname>PGresult</structname>. This can be unworkable for commands

that return a large number of rows. For such cases, applications can use

</para>

<para>

at a specified position in a path:

<screen>

CREATE FUNCTION ins_label(ltree, int, text) RETURNS ltree

transactions might do, or it will not successfully commit. It is

important that an environment which uses this technique have a

generalized way of handling serialization failures (which always return

predict exactly which transactions might contribute to the read/write

dependencies and need to be rolled back to prevent serialization

anomalies. The monitoring of read/write dependencies has a cost, as does

<listitem>

<para>

<function>fsm_page_contents</function> shows the internal node structure

<screen>

test=# SELECT fsm_page_contents(get_raw_page('pg_class', 'fsm', 0));

</screen>

</listitem>

<listitem>

<para>

</para>

</listitem>

<listitem>

One might expect that writing <command>SELECT</command> directly

would accomplish this result, but at

present the only accepted way to do it is

such as <command>SELECT</command>, will be rejected as an error

unless it has an <literal>INTO</literal> clause as discussed in the

next section.

</indexterm>

<para>

columns) can be assigned to a record variable, row-type variable, or list

of scalar variables. This is done by writing the base SQL command and

adding an <literal>INTO</literal> clause. For example,

<para>

The <literal>INTO</literal> clause specifies where the results of

or variable list is provided, it must exactly match the structure

of the command's results; if a

record variable is provided, it will configure itself to match the

<para>

The <literal>FOREACH</literal> loop is much like a <literal>FOR</literal> loop,

it iterates through the elements of an array value.

(In general, <literal>FOREACH</literal> is meant for looping through

components of a composite-valued expression; variants for looping

<para>

Another way to understand this is that variable substitution can only

database objects are referenced by the command. (If you want to do

that, you must build a command string dynamically, as explained in

<xref linkend="plpgsql-statements-executing-dyn"/>.)

<para>

By default, <application>PL/pgSQL</application> will report an error if a name

You can fix such a problem by renaming the variable or column,

or by qualifying the ambiguous reference, or by telling

<application>PL/pgSQL</application> which interpretation to prefer.

<itemizedlist>

<listitem>

<para>

table used in the command or a reference to a variable of the function,

<application>PL/SQL</application> treats it as a column name.

By default, <application>PL/pgSQL</application> will throw an error

$$ LANGUAGE plpythonu;

</programlisting>

the corresponding position.

</para>

<para>

Any extra dictionary key/value pairs are ignored. Missing keys are

treated as errors.

<symbol>None</symbol> with the corresponding column name as the key.

</para>

</listitem>

<listitem>

<para>

The Tcl script contained in <replaceable>command</replaceable> is

error, that entire subtransaction is rolled back before returning the

error out to the surrounding Tcl code.

See <xref linkend="pltcl-subtransactions"/> for more details and an

PL/Tcl's <function>elog</function> command. Such errors can be caught

within Tcl using the Tcl <function>catch</function> command. If an

error is not caught but is allowed to propagate out to the top level of

function's calling query.

</para>

subtransaction, which is rolled back on error, so that any

partially-completed operation is automatically cleaned up.)

Again, if an error propagates out to the top level without being caught,

</para>

<para>