</synopsis>

where <replaceable>salt</replaceable>, <replaceable>StoredKey</replaceable> and

<replaceable>ServerKey</replaceable> are in Base64 encoded format. This format is

the same as that specified by RFC 5803.

the same as that specified by<ulink url="https://tools.ietf.org/html/rfc5803">RFC 5803</ulink>.

</para>

<para>

</varlistentry>

<varlistentry>

<term>RFC 3629</term>

<term><ulink url="https://tools.ietf.org/html/rfc3629">RFC 3629</ulink></term>

<listitem>

<para>

<listitem>

<para>

<link linkend="auth-ident">Ident authentication</link>, which

relies on an <quote>Identification Protocol</quote> (RFC 1413)

relies on an <quote>Identification Protocol</quote>

(<ulink url="https://tools.ietf.org/html/rfc1413">RFC 1413</ulink>)

service on the client's machine. (On local Unix-socket connections,

this is treated as peer authentication.)

</para>

<para>

<productname>GSSAPI</productname> is an industry-standard protocol

for secure authentication defined in RFC 2743.

for secure authentication defined in

<ulink url="https://tools.ietf.org/html/rfc2743">RFC 2743</ulink>.

<productname>PostgreSQL</productname>

supports <productname>GSSAPI</productname> for use as either an encrypted,

<para>

The <quote>Identification Protocol</quote> is described in

RFC 1413. Virtually every Unix-like

<ulink url="https://tools.ietf.org/html/rfc1413">RFC 1413</ulink>.

Virtually every Unix-like

operating system ships with an ident server that listens on TCP

port 113 by default. The basic functionality of an ident server

is to answer questions like <quote>What user initiated the

<para>

Set to 1 to make the connection between PostgreSQL and the LDAP server

use TLS encryption. This uses the <literal>StartTLS</literal>

operation perRFC 4513. See also the <literal>ldapscheme</literal>

option for an alternative.

operation per<ulink url="https://tools.ietf.org/html/rfc4513">RFC 4513</ulink>.

See also the <literal>ldapscheme</literal>option for an alternative.

</para>

</listitem>

</varlistentry>

<term><literal>ldapurl</literal></term>

<listitem>

<para>

An RFC 4516 LDAP URL. This is an alternative way to write some of the

An <ulink url="https://tools.ietf.org/html/rfc4516">RFC 4516</ulink>

LDAP URL. This is an alternative way to write some of the

other LDAP options in a more compact and standard form. The format is

<synopsis>

ldap[s]://<replaceable>host</replaceable>[:<replaceable>port</replaceable>]/<replaceable>basedn</replaceable>[?[<replaceable>attribute</replaceable>][?[<replaceable>scope</replaceable>][?[<replaceable>filter</replaceable>]]]]

If <productname>PostgreSQL</productname> was compiled with

<productname>OpenLDAP</productname> as the LDAP client library, the

<literal>ldapserver</literal> setting may be omitted. In that case, a

list of host names and ports is looked up via RFC 2782 DNS SRV records.

list of host names and ports is looked up via

<ulink url="https://tools.ietf.org/html/rfc2782">RFC 2782</ulink> DNS SRV records.

The name <literal>_ldap._tcp.DOMAIN</literal> is looked up, where

<literal>DOMAIN</literal> is extracted from <literal>ldapbasedn</literal>.

</para>

ISO 8601 specifies the use of uppercase letter <literal>T</literal> to separate

the date and time. <productname>PostgreSQL</productname> accepts that format on

input, but on output it uses a space rather than <literal>T</literal>, as shown

above. This is for readability and for consistency with RFC 3339 as

above. This is for readability and for consistency with

<ulink url="https://tools.ietf.org/html/rfc3339">RFC 3339</ulink> as

well as some other database systems.

</para>

</note>

<para>

The data type <type>uuid</type> stores Universally Unique Identifiers

(UUID) as defined by RFC 4122, ISO/IEC 9834-8:2005, and related standards.

(UUID) as defined by <ulink url="https://tools.ietf.org/html/rfc4122">RFC 4122</ulink>,

ISO/IEC 9834-8:2005, and related standards.

(Some systems refer to this data type as a globally unique identifier, or

GUID,<indexterm><primary>GUID</primary></indexterm> instead.) This

identifier is a 128-bit quantity that is generated by an algorithm chosen

<literal>%z</literal> - is replaced by the time zone offset from

UTC; a leading plus sign stands for east of UTC, a minus sign for

west of UTC, hours and minutes follow with two digits each and no

delimiter between them (common form for RFC 822 date headers).

delimiter between them (common form for<ulink url="https://tools.ietf.org/html/rfc822">RFC 822</ulink> date headers).

</para>

</listitem>

<listitem>

<para>

The <literal>base64</literal> format is that

of <ulink url="https://tools.ietf.org/html/rfc2045#section-6.8">RFC

2045 Section 6.8</ulink>. As per the RFC, encoded lines are

2045 Section 6.8</ulink>. As per the<acronym>RFC</acronym>, encoded lines are

broken at 76 characters. However instead of the MIME CRLF

end-of-line marker, only a newline is used for end-of-line.

The <function>decode</function> function ignores carriage-return,

</para>

<para>

RFC 7159 specifies that JSON strings should be encoded in UTF8.

<acronym>RFC</acronym> 7159 specifies that JSON strings should be encoded in UTF8.

It is therefore not possible for the JSON

types to conform rigidly to the JSON specification unless the database

encoding is UTF8. Attempts to directly include characters that

</para>

<para>

RFC 7159 permits JSON strings to contain Unicode escape sequences

<acronym>RFC</acronym> 7159 permits JSON strings to contain Unicode escape sequences

denoted by <literal>\u<replaceable>XXXX</replaceable></literal>. In the input

function for the <type>json</type> type, Unicode escapes are allowed

regardless of the database encoding, and are checked only for syntactic

<literal>ldap://</literal> will be recognized as an LDAP URL and an

LDAP query will be performed. The result must be a list of

<literal>keyword = value</literal> pairs which will be used to set

connection options. The URL must conform to RFC 1959 and be of the

form

connection options. The URL must conform to

<ulink url="https://tools.ietf.org/html/rfc1959">RFC 1959</ulink>

and be of the form

<synopsis>

ldap://[<replaceable>hostname</replaceable>[:<replaceable>port</replaceable>]]/<replaceable>search_base</replaceable>?<replaceable>attribute</replaceable>?<replaceable>search_scope</replaceable>?<replaceable>filter</replaceable>

</synopsis>

<title>PGP Encryption Functions</title>

<para>

The functions here implement the encryption part of the OpenPGP (RFC 4880)

The functions here implement the encryption part of the OpenPGP

(<ulink url="https://tools.ietf.org/html/rfc4880">RFC 4880</ulink>)

standard. Supported are both symmetric-key and public-key encryption.

</para>

<para>

Whether to convert <literal>\n</literal> into <literal>\r\n</literal> when

encrypting and <literal>\r\n</literal> to <literal>\n</literal> when

decrypting. RFC 4880 specifies that text data should be stored using

decrypting.<acronym>RFC</acronym> 4880 specifies that text data should be stored using

<literal>\r\n</literal> line-feeds. Use this to get fully RFC-compliant

behavior.

</para>

<para>

Do not protect data with SHA-1. The only good reason to use this

option is to achieve compatibility with ancient PGP products, predating

the addition of SHA-1 protected packets to RFC 4880.

the addition of SHA-1 protected packets to<acronym>RFC</acronym> 4880.

Recent gnupg.org and pgp.com software supports it fine.

</para>

<literallayout>

is willing or unwilling to perform <acronym>GSSAPI</acronym> encryption,

respectively. The frontend might close the connection at this point

if it is dissatisfied with the response. To continue after

<literal>G</literal>, using the GSSAPI C bindings as discussed in RFC2744

<literal>G</literal>, using the GSSAPI C bindings as discussed in

<ulink url="https://tools.ietf.org/html/rfc2744">RFC 2744</ulink>

or equivalent, perform a <acronym>GSSAPI</acronym> initialization by

calling <function>gss_init_sec_context()</function> in a loop and sending

the result to the server, starting with an empty input and then with each

The implemented SASL mechanisms at the moment

are <literal>SCRAM-SHA-256</literal> and its variant with channel

binding <literal>SCRAM-SHA-256-PLUS</literal>. They are described in

detail in RFC 7677 and RFC 5802.

detail in <ulink url="https://tools.ietf.org/html/rfc7677">RFC 7677</ulink>

and <ulink url="https://tools.ietf.org/html/rfc5802">RFC 5802</ulink>.

</para>

<para>