<ulink

url="https://en.wikipedia.org/wiki/Server_Name_Indication">

Server Name Indication</ulink>,

</para>

</listitem>

</varlistentry>

</synopsis>

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

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

</para>

<para>

</listitem>

<listitem>

<para>

</para>

</listitem>

<listitem>

</varlistentry>

<varlistentry>

<listitem>

<para>

entire <literal>Distinguished Name (DN)</literal> of the certificate.

This option is probably best used in conjunction with a username map.

The comparison is done with the <literal>DN</literal> in

format. To see the <literal>DN</literal> of a client certificate

in this format, do

<programlisting>

<para>

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

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

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

this is treated as peer authentication.)

</para>

<para>

The method <literal>scram-sha-256</literal> performs SCRAM-SHA-256

authentication, as described in

is a challenge-response scheme that prevents password sniffing on

untrusted connections and supports storing passwords on the server in a

cryptographically hashed form that is thought to be secure.

<para>

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

for secure authentication defined in

<productname>PostgreSQL</productname>

supports <productname>GSSAPI</productname> for authentication,

communications encryption, or both.

<para>

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

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

<para>

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

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

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

</para>

</listitem>

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

<listitem>

<para>

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>

<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

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

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

</para>

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

well as some other database systems.

</para>

</note>

<para>

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

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

<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

</para>

</listitem>

<listitem>

<listitem>

<para>

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

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.

<function>uuid_extract_version</function> (uuid) <returnvalue>smallint</returnvalue>

</synopsis>

This function extracts the version from a UUID of the variant described by

other variants, this function returns null. For example, for a UUID

generated by <function>gen_random_uuid</function>, this function will

return 4.

values, with an additional SQL/JSON null value, and composite data structures

that use JSON arrays and objects. The model is a formalization of the implied

data model in the JSON specification

</para>

<para>

<para>

JSON data types are for storing JSON (JavaScript Object Notation)

7159</ulink>. Such data can also be stored as <type>text</type>, but

the JSON data types have the advantage of enforcing that each

stored value is valid according to the JSON rules. There are also

connection parameters. There are two accepted formats for these strings:

plain keyword/value strings

and URIs. URIs generally follow

3986</ulink>, except that multi-host connection strings are allowed

as further described below.

</para>

<para>

The connection <acronym>URI</acronym> needs to be encoded with <ulink

if it includes symbols with special meaning in any of its parts. Here is

an example where the equal sign (<literal>=</literal>) is replaced with

<literal>%3D</literal> and the space character with

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

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>

<para>

For backward compatibility with earlier versions of PostgreSQL, the host

IP address is verified in a manner different

The host IP address is always matched against <literal>dNSName</literal>

SANs as well as <literal>iPAddress</literal> SANs, and can be matched

against the Common Name attribute if no relevant SANs exist.

<para>

The functions here implement the encryption part of the OpenPGP

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

</para>

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

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

</para>

<para>

</indexterm>

writes column values separated by commas, applying the quoting

rules described in

This output is compatible with the CSV format of the server's

<command>COPY</command> command.

A header line with column names is generated unless

<para>

<literal>email</literal> does not support all valid email characters as

Specifically, the only non-alphanumeric characters supported for

email user names are period, dash, and underscore.

</para>

<xref linkend="uuid-ossp-functions"/> shows the functions available to

generate UUIDs.

The relevant standards ITU-T Rec. X.667, ISO/IEC 9834-8:2005, and

specify four algorithms for generating UUIDs, identified by the

version numbers 1, 3, 4, and 5. (There is no version 2 algorithm.)

Each of these algorithms could be suitable for a different set of