where salt , StoredKey and
ServerKey are in Base64 encoded format. This format is
- the same as that specified by RFC 5803 .
+ the same as that specified by
RFC 5803 .
Ident authentication, which
- relies on an Identification Protocol
(RFC 1413)
+ relies on an Identification Protocol
service on the client's machine. (On local Unix-socket connections,
this is treated as peer authentication.)
GSSAPI is an industry-standard protocol
- for secure authentication defined in RFC 2743.
+ for secure authentication defined in
supports
GSSAPI for use as either an encrypted,
The Identification Protocol
is described in
- RFC 1413. Virtually every Unix-like
+ 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 What user initiated the
Set to 1 to make the connection between PostgreSQL and the LDAP server
use TLS encryption. This uses the StartTLS
- operation per RFC 4513. See also the ldapscheme
- option for an alternative.
+ operation per
RFC 4513 .
+ See also the ldapscheme option for an alternative.
ldapurl
- An RFC 4516 LDAP URL. This is an alternative way to write some of the
+ 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
ldap[s]://host [:port ]/basedn [?[attribute ][?[scope ][?[filter ]]]]
If
PostgreSQL was compiled with
OpenLDAP as the LDAP client library, the
ldapserver 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
+
RFC 2782 DNS SRV records.
The name _ldap._tcp.DOMAIN is looked up, where
DOMAIN is extracted from ldapbasedn .
ISO 8601 specifies the use of uppercase letter T to separate
the date and time.
PostgreSQL accepts that format on
input, but on output it uses a space rather than T , as shown
- above. This is for readability and for consistency with RFC 3339 as
+ above. This is for readability and for consistency with
well as some other database systems.
The data type uuid stores Universally Unique Identifiers
- (UUID) as defined by RFC 4122, ISO/IEC 9834-8:2005, and related standards.
+ (UUID) as defined by
RFC 4122 ,
+ ISO/IEC 9834-8:2005, and related standards.
(Some systems refer to this data type as a globally unique identifier, or
identifier is a 128-bit quantity that is generated by an algorithm chosen
%z - 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
RFC 822 date headers).
The base64 format is that
- 2045 Section 6.8. As per the RFC , encoded lines are
+ 2045 Section 6.8. As per the
RFC , 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 decode function ignores carriage-return,
- RFC 7159 specifies that JSON strings should be encoded in UTF8.
+
RFC 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
- RFC 7159 permits JSON strings to contain Unicode escape sequences
+
RFC 7159 permits JSON strings to contain Unicode escape sequences
denoted by \uXXXX . In the input
function for the json type, Unicode escapes are allowed
regardless of the database encoding, and are checked only for syntactic
ldap:// will be recognized as an LDAP URL and an
LDAP query will be performed. The result must be a list of
keyword = value 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
+ and be of the form
ldap://[hostname [:port ]]/search_base ?attribute ?search_scope ?filter
PGP Encryption Functions
- The functions here implement the encryption part of the OpenPGP (RFC 4880)
+ The functions here implement the encryption part of the OpenPGP
standard. Supported are both symmetric-key and public-key encryption.
Whether to convert \n into \r\n when
encrypting and \r\n to \n when
- decrypting. RFC 4880 specifies that text data should be stored using
+ decrypting.
RFC 4880 specifies that text data should be stored using
\r\n line-feeds. Use this to get fully RFC-compliant
behavior.
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
RFC 4880.
Recent gnupg.org and pgp.com software supports it fine.
is willing or unwilling to perform
GSSAPI encryption,
respectively. The frontend might close the connection at this point
if it is dissatisfied with the response. To continue after
- G , using the GSSAPI C bindings as discussed in RFC2744
+ G , using the GSSAPI C bindings as discussed in
or equivalent, perform a
GSSAPI initialization by
calling gss_init_sec_context() 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 SCRAM-SHA-256 and its variant with channel
binding SCRAM-SHA-256-PLUS . They are described in
- detail in RFC 7677 and RFC 5802.
email does not support all valid email characters as
- defined by RFC 5322. Specifically, the only non-alphanumeric
- characters supported for email user names are period, dash, and
- underscore.
+ Specifically, the only non-alphanumeric characters supported for
+ email user names are period, dash, and underscore.
shows the functions available to
generate UUIDs.
- The relevant standards ITU-T Rec. X.667, ISO/IEC 9834-8:2005, and RFC
- 4122 specify four algorithms for generating UUIDs, identified by the
+ 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
applications.