Functions and Operators
functions
operators
PostgreSQL provides a large number of
functions and operators for the built-in data types. Users can also
define their own functions and operators, as described in
. The
psql commands \df and
\do can be used to show the list of all actually
available functions and operators, respectively.
If you are concerned about portability then take note that most of
the functions and operators described in this chapter, with the
exception of the most trivial arithmetic and comparison operators
and some explicitly marked functions, are not specified by the
SQL
standard. Some of the extended functionality is present in other
SQL implementations, and in many cases this
functionality is compatible and consistent between various products.
Logical Operators
operators
logical
Boolean
operators
operators, logical
The usual logical operators are available:
and
operator
or
operator
not
operator
AND>
OR>
NOT>
SQL uses a three-valued Boolean logic where the null value represents
unknown
. Observe the following truth tables:
a
b
a AND b
a OR b
TRUE
TRUE
TRUE
TRUE
TRUE
FALSE
FALSE
TRUE
TRUE
NULL
NULL
TRUE
FALSE
FALSE
FALSE
FALSE
FALSE
NULL
FALSE
NULL
NULL
NULL
NULL
NULL
a
NOT a
TRUE
FALSE
FALSE
TRUE
NULL
NULL
Comparison Operators
comparison
operators
The usual comparison operators are available, shown in .
Comparison Operators
Operator
Description
<
less than
>
greater than
<=
less than or equal to
>=
greater than or equal to
=
equal
<> or !=
not equal
The != operator is converted to
<> in the parser stage. It is not
possible to implement != and
<> operators that do different things.
Comparison operators are available for all data types where this
makes sense. All comparison operators are binary operators that
return values of type boolean; expressions like
1 < 2 < 3 are not valid (because there is
no < operator to compare a Boolean value with
3).
between
In addition to the comparison operators, the special
BETWEEN construct is available.
a BETWEEN x AND y
is equivalent to
a >= x AND a <= y
Similarly,
a NOT BETWEEN x AND y
is equivalent to
a < x OR a > y
There is no difference between the two respective forms apart from
the CPU cycles required to rewrite the first one
into the second one internally.
To check whether a value is or is not null, use the constructs
expression IS NULL
expression IS NOT NULL
or the equivalent, but nonstandard, constructs
expression ISNULL
expression NOTNULL
Do not write
expression = NULL
because NULL> is not equal to
NULL>. (The null value represents an unknown value,
and it is not known whether two unknown values are equal.)
Some applications may (incorrectly) require that
expression = NULL
returns true if expression evaluates to
the null value. To support these applications, the run-time option
transform_null_equals can be turned on (e.g.,
SET transform_null_equals TO ON;).
PostgreSQL will then convert
x = NULL clauses to
x IS NULL. This was
the default behavior in releases 6.5 through 7.1.
Boolean values can also be tested using the constructs
expression IS TRUE
expression IS NOT TRUE
expression IS FALSE
expression IS NOT FALSE
expression IS UNKNOWN
expression IS NOT UNKNOWN
These are similar to IS NULL in that they will
always return true or false, never a null value, even when the operand is null.
A null input is treated as the logical value unknown>.
Mathematical Functions and Operators
Mathematical operators are provided for many
PostgreSQL types. For types without
common mathematical conventions for all possible permutations
(e.g., date/time types) we
describe the actual behavior in subsequent sections.
shows the available mathematical operators.
Mathematical Operators
Operator
Description
Example
Result
+
addition
2 + 3
5
-
subtraction
2 - 3
-1
*
multiplication
2 * 3
6
/
division (integer division truncates results)
4 / 2
2
%
modulo (remainder)
5 % 4
1
^
exponentiation
2.0 ^ 3.0
8
|/
square root
|/ 25.0
5
||/
cube root
||/ 27.0
3
!
factorial
5 !
120
!!
factorial (prefix operator)
!! 5
120
@
absolute value
@ -5.0
5
&
bitwise AND
91 & 15
11
|
bitwise OR
32 | 3
35
#
bitwise XOR
17 # 5
20
~
bitwise NOT
~1
-2
<<
biwise shift left
1 << 4
16
>>
bitwise shift right
8 >> 2
2
The bitwise operators are also available for the bit
string types bit and bit varying, as
shown in .
Bit string operands of &, |,
and # must be of equal length. When bit
shifting, the original length of the string is preserved, as shown
in the table.
Bit String Bitwise Operators
Example
Result
B'10001' & B'01101'
00001
B'10001' | B'01101'
11101
B'10001' # B'01101'
11110
~ B'10001'
01110
B'10001' << 3
01000
B'10001' >> 2
00100
shows the available
mathematical functions. In the table, dp
indicates double precision. Many of these functions
are provided in multiple forms with different argument types.
Except where noted, any given form of a function returns the same
datatype as its argument.
The functions working with double precision data are mostly
implemented on top of the host system's C library; accuracy and behavior in
boundary cases may therefore vary depending on the host system.
Mathematical Functions
Function
Return Type
Description
Example
Result
abs>(x)
(same as x>)
absolute value
abs(-17.4)
17.4
cbrt(dp)
dp
cube root
cbrt(27.0)
3
ceil(dp or numeric)
(same as input)
smallest integer not less than argument
ceil(-42.8)
-42
degrees(dp)
dp
radians to degrees
degrees(0.5)
28.6478897565412
exp(dp or numeric)
(same as input)
exponential
exp(1.0)
2.71828182845905
floor(dp or numeric)
(same as input)
largest integer not greater than argument
floor(-42.8)
-43
ln(dp or numeric)
(same as input)
natural logarithm
ln(2.0)
0.693147180559945
log(dp or numeric)
(same as input)
base 10 logarithm
log(100.0)
2
log(b numeric,
x numeric)
numeric
logarithm to base b
log(2.0, 64.0)
6.0000000000
mod(y,
x)
(same as argument types)
remainder of y/x
mod(9,4)
1
pi()
dp
π
constant
pi()
3.14159265358979
pow(a dp,
b dp)
dp
a> raised to the power of b
pow(9.0, 3.0)
729
pow(a numeric,
b numeric)
numeric
a> raised to the power of b
pow(9.0, 3.0)
729
radians(dp)
dp
degrees to radians
radians(45.0)
0.785398163397448
random()
dp
random value between 0.0 and 1.0
random()
round(dp or numeric)
(same as input)
round to nearest integer
round(42.4)
42
round(v numeric, s integer)
numeric
round to s decimal places
round(42.4382, 2)
42.44
setseed(dp)
int32
set seed for subsequent random() calls
setseed(0.54823)
1177314959
sign(dp or numeric)
(same as input)
sign of the argument (-1, 0, +1)
sign(-8.4)
-1
sqrt(dp or numeric)
(same as input)
square root
sqrt(2.0)
1.4142135623731
trunc(dp or numeric)
(same as input)
truncate toward zero
trunc(42.8)
42
trunc(v numeric, s integer)
numeric
truncate to s decimal places
trunc(42.4382, 2)
42.43
Finally, shows the
available trigonometric functions. All trigonometric functions
take arguments and return values of type double
precision.
Trigonometric Functions
Function
Description
acos(x)
inverse cosine
asin(x)
inverse sine
atan(x)
inverse tangent
atan2(x,
y)
inverse tangent of
x/y
cos(x)
cosine
cot(x)
cotangent
sin(x)
sine
tan(x)
tangent
String Functions and Operators
This section describes functions and operators for examining and
manipulating string values. Strings in this context include values
of all the types character, character
varying, and text. Unless otherwise noted, all
of the functions listed below work on all of these types, but be
wary of potential effects of the automatic padding when using the
character type. Generally, the functions described
here also work on data of non-string types by converting that data
to a string representation first. Some functions also exist
natively for the bit-string types.
SQL defines some string functions with a special syntax where
certain key words rather than commas are used to separate the
arguments. Details are in .
These functions are also implemented using the regular syntax for
function invocation. (See .)
SQL String Functions and Operators
Function
Return Type
Description
Example
Result
string ||
string
text
String concatenation
character strings
concatenation
'Post' || 'greSQL'
PostgreSQL
bit_length(string)
integer
Number of bits in string
bit_length('jose')
32
char_length(string) or character_length(string)
integer
Number of characters in string
character strings
length
length
character strings
character strings, length
char_length('jose')
4
convert(string
using conversion_name)
text
Change encoding using specified conversion name. Conversions
can be defined by CREATE CONVERSION. Also
there are some pre-defined conversion names. See for available conversion
names.
convert('PostgreSQL' using iso_8859_1_to_utf_8)
'PostgreSQL' in Unicode (UTF-8) encoding
lower(string)
text
Convert string to lower case
lower('TOM')
tom
octet_length(string)
integer
Number of bytes in string
octet_length('jose')
4
overlay(string placing string from integer for integer)
text
Replace substring
overlay
overlay('Txxxxas' placing 'hom' from 2 for 4)
Thomas
position(substring in string)
integer
Location of specified substring
position('om' in 'Thomas')
3
substring(string from integer for integer)
text
Extract substring
substring
substring('Thomas' from 2 for 3)
hom
substring(string from pattern)
text
Extract substring matching POSIX regular expression
substring
substring('Thomas' from '...$')
mas
substring(string from pattern for escape)
text
Extract substring matching SQL regular
expression
substring
substring('Thomas' from '%#"o_a#"_' for '#')
oma
trim(leading | trailing | both
characters from
string)
text
Remove the longest string containing only the
characters (a space by default) from the
start/end/both ends of the string.
trim(both 'x' from 'xTomxx')
Tom
upper(string)
text
Convert string to upper case
upper('tom')
TOM
Additional string manipulation functions are available and are
listed in . Some of them are used internally to implement the
SQL-standard string functions listed in .
Other String Functions
Function
Return Type
Description
Example
Result
ascii(text)
integer
ASCII code of the first character of the argument
ascii('x')
120
btrim(string text, characters text)
text
Remove the longest string consisting only of characters
in characters from the start and end of
string.
btrim('xyxtrimyyx','xy')
trim
chr(integer)
text
Character with the given ASCII code
chr(65)
A
convert(string
text,
src_encoding name,
dest_encoding name)
text
Convert string to dest_encoding.
The original encoding is specified by
src_encoding. If
src_encoding is omitted, database
encoding is assumed.
convert('text_in_unicode', 'UNICODE', 'LATIN1')
text_in_unicode represented in ISO 8859-1 encoding
decode(string text,
type text)
bytea
Decode binary data from string previously
encoded with encode>. Parameter type is same as in encode>.
decode('MTIzAAE=', 'base64')
123\000\001
encode(data bytea,
type text)
text
Encode binary data to ASCII-only representation. Supported
types are: base64>, hex>, escape>.
encode('123\\000\\001', 'base64')
MTIzAAE=
initcap(text)
text
Convert first letter of each word (whitespace-separated) to upper case
initcap('hi thomas')
Hi Thomas
length(string)
integer
Number of characters in string
character strings
length
length
character strings
character strings, length
length('jose')
4
lpad(string text,
length integer
, fill text)
text
Fill up the string to length
length by prepending the characters
fill (a space by default). If the
string is already longer than
length then it is truncated (on the
right).
lpad('hi', 5, 'xy')
xyxhi
ltrim(string text, characters text)
text
Remove the longest string containing only characters from
characters from the start of the string.
ltrim('zzzytrim','xyz')
trim
md5(string text)
text
Calculates the MD5 hash of given string, returning the result in hexadecimal.
md5('abc')
900150983cd24fb0d6963f7d28e17f72
pg_client_encoding()
name
Current client encoding name
pg_client_encoding()
SQL_ASCII
quote_ident(string text)
text
Return the given string suitably quoted to be used as an identifier
in an SQL statement string.
Quotes are added only if necessary (i.e., if the string contains
non-identifier characters or would be case-folded).
Embedded quotes are properly doubled.
quote_ident('Foo')
"Foo"
quote_literal(string text)
text
Return the given string suitably quoted to be used as a string literal
in an SQL statement string.
Embedded quotes and backslashes are properly doubled.
quote_literal('O\'Reilly')
'O''Reilly'
repeat(text, integer)
text
Repeat text a number of times
repeat('Pg', 4)
PgPgPgPg
replace(string text,
from text,
to text)
text
Replace all occurrences in string of substring
from with substring to.
replace('abcdefabcdef', 'cd', 'XX')
abXXefabXXef
rpad(string text,
length integer
, fill text)
text
Fill up the string to length
length by appending the characters
fill (a space by default). If the
string is already longer than
length then it is truncated.
rpad('hi', 5, 'xy')
hixyx
rtrim(string
text, characters text)
text
Remove the longest string containing only characters from
characters from the end of the string.
rtrim('trimxxxx','x')
trim
split_part(string text,
delimiter text,
field integer)
text
Split string on delimiter
and return the given field (counting from one)
split_part('abc~@~def~@~ghi','~@~',2)
def
strpos(string, substring)
text
Location of specified substring (same as
position(substring in
string), but note the reversed
argument order)
strpos('high','ig')
2
substr(string, from , count)
text
Extract substring (same as
substring(string from from for count))
substr('alphabet', 3, 2)
ph
to_ascii(text
, encoding)
text
Convert text to ASCII from other encoding
The to_ascii function supports conversion from
LATIN1>, LATIN2>, and WIN1250> only.
to_ascii('Karel')
Karel
to_hex(number integer
or bigint)
text
Convert number to its equivalent hexadecimal
representation
to_hex(9223372036854775807)
7fffffffffffffff
translate(string
text,
from text,
to text)
text
Any character in string that matches a
character in the from set is replaced by
the corresponding character in the to
set.
translate('12345', '14', 'ax')
a23x5
Built-in Conversions
Conversion Name
The conversion names follow a standard naming scheme: The
official name of the source encoding with all
non-alphanumeric characters replaced by underscores followed
by _to_ followed by the equally processed
destination encoding name. Therefore the names might deviate
from the customary encoding names.
Source Encoding
Destination Encoding
ascii_to_mic
SQL_ASCII
MULE_INTERNAL
ascii_to_utf_8
SQL_ASCII
UNICODE
big5_to_euc_tw
BIG5
EUC_TW
big5_to_mic
BIG5
MULE_INTERNAL
big5_to_utf_8
BIG5
UNICODE
euc_cn_to_mic
EUC_CN
MULE_INTERNAL
euc_cn_to_utf_8
EUC_CN
UNICODE
euc_jp_to_mic
EUC_JP
MULE_INTERNAL
euc_jp_to_sjis
EUC_JP
SJIS
euc_jp_to_utf_8
EUC_JP
UNICODE
euc_kr_to_mic
EUC_KR
MULE_INTERNAL
euc_kr_to_utf_8
EUC_KR
UNICODE
euc_tw_to_big5
EUC_TW
BIG5
euc_tw_to_mic
EUC_TW
MULE_INTERNAL
euc_tw_to_utf_8
EUC_TW
UNICODE
gb18030_to_utf_8
GB18030
UNICODE
gbk_to_utf_8
GBK
UNICODE
iso_8859_10_to_utf_8
LATIN6
UNICODE
iso_8859_13_to_utf_8
LATIN7
UNICODE
iso_8859_14_to_utf_8
LATIN8
UNICODE
iso_8859_15_to_utf_8
LATIN9
UNICODE
iso_8859_16_to_utf_8
LATIN10
UNICODE
iso_8859_1_to_mic
LATIN1
MULE_INTERNAL
iso_8859_1_to_utf_8
LATIN1
UNICODE
iso_8859_2_to_mic
LATIN2
MULE_INTERNAL
iso_8859_2_to_utf_8
LATIN2
UNICODE
iso_8859_2_to_windows_1250
LATIN2
WIN1250
iso_8859_3_to_mic
LATIN3
MULE_INTERNAL
iso_8859_3_to_utf_8
LATIN3
UNICODE
iso_8859_4_to_mic
LATIN4
MULE_INTERNAL
iso_8859_4_to_utf_8
LATIN4
UNICODE
iso_8859_5_to_koi8_r
ISO_8859_5
KOI8
iso_8859_5_to_mic
ISO_8859_5
MULE_INTERNAL
iso_8859_5_to_utf_8
ISO_8859_5
UNICODE
iso_8859_5_to_windows_1251
ISO_8859_5
WIN
iso_8859_5_to_windows_866
ISO_8859_5
ALT
iso_8859_6_to_utf_8
ISO_8859_6
UNICODE
iso_8859_7_to_utf_8
ISO_8859_7
UNICODE
iso_8859_8_to_utf_8
ISO_8859_8
UNICODE
iso_8859_9_to_utf_8
LATIN5
UNICODE
johab_to_utf_8
JOHAB
UNICODE
koi8_r_to_iso_8859_5
KOI8
ISO_8859_5
koi8_r_to_mic
KOI8
MULE_INTERNAL
koi8_r_to_utf_8
KOI8
UNICODE
koi8_r_to_windows_1251
KOI8
WIN
koi8_r_to_windows_866
KOI8
ALT
mic_to_ascii
MULE_INTERNAL
SQL_ASCII
mic_to_big5
MULE_INTERNAL
BIG5
mic_to_euc_cn
MULE_INTERNAL
EUC_CN
mic_to_euc_jp
MULE_INTERNAL
EUC_JP
mic_to_euc_kr
MULE_INTERNAL
EUC_KR
mic_to_euc_tw
MULE_INTERNAL
EUC_TW
mic_to_iso_8859_1
MULE_INTERNAL
LATIN1
mic_to_iso_8859_2
MULE_INTERNAL
LATIN2
mic_to_iso_8859_3
MULE_INTERNAL
LATIN3
mic_to_iso_8859_4
MULE_INTERNAL
LATIN4
mic_to_iso_8859_5
MULE_INTERNAL
ISO_8859_5
mic_to_koi8_r
MULE_INTERNAL
KOI8
mic_to_sjis
MULE_INTERNAL
SJIS
mic_to_windows_1250
MULE_INTERNAL
WIN1250
mic_to_windows_1251
MULE_INTERNAL
WIN
mic_to_windows_866
MULE_INTERNAL
ALT
sjis_to_euc_jp
SJIS
EUC_JP
sjis_to_mic
SJIS
MULE_INTERNAL
sjis_to_utf_8
SJIS
UNICODE
tcvn_to_utf_8
TCVN
UNICODE
uhc_to_utf_8
UHC
UNICODE
utf_8_to_ascii
UNICODE
SQL_ASCII
utf_8_to_big5
UNICODE
BIG5
utf_8_to_euc_cn
UNICODE
EUC_CN
utf_8_to_euc_jp
UNICODE
EUC_JP
utf_8_to_euc_kr
UNICODE
EUC_KR
utf_8_to_euc_tw
UNICODE
EUC_TW
utf_8_to_gb18030
UNICODE
GB18030
utf_8_to_gbk
UNICODE
GBK
utf_8_to_iso_8859_1
UNICODE
LATIN1
utf_8_to_iso_8859_10
UNICODE
LATIN6
utf_8_to_iso_8859_13
UNICODE
LATIN7
utf_8_to_iso_8859_14
UNICODE
LATIN8
utf_8_to_iso_8859_15
UNICODE
LATIN9
utf_8_to_iso_8859_16
UNICODE
LATIN10
utf_8_to_iso_8859_2
UNICODE
LATIN2
utf_8_to_iso_8859_3
UNICODE
LATIN3
utf_8_to_iso_8859_4
UNICODE
LATIN4
utf_8_to_iso_8859_5
UNICODE
ISO_8859_5
utf_8_to_iso_8859_6
UNICODE
ISO_8859_6
utf_8_to_iso_8859_7
UNICODE
ISO_8859_7
utf_8_to_iso_8859_8
UNICODE
ISO_8859_8
utf_8_to_iso_8859_9
UNICODE
LATIN5
utf_8_to_johab
UNICODE
JOHAB
utf_8_to_koi8_r
UNICODE
KOI8
utf_8_to_sjis
UNICODE
SJIS
utf_8_to_tcvn
UNICODE
TCVN
utf_8_to_uhc
UNICODE
UHC
utf_8_to_windows_1250
UNICODE
WIN1250
utf_8_to_windows_1251
UNICODE
WIN
utf_8_to_windows_1256
UNICODE
WIN1256
utf_8_to_windows_866
UNICODE
ALT
utf_8_to_windows_874
UNICODE
WIN874
windows_1250_to_iso_8859_2
WIN1250
LATIN2
windows_1250_to_mic
WIN1250
MULE_INTERNAL
windows_1250_to_utf_8
WIN1250
UNICODE
windows_1251_to_iso_8859_5
WIN
ISO_8859_5
windows_1251_to_koi8_r
WIN
KOI8
windows_1251_to_mic
WIN
MULE_INTERNAL
windows_1251_to_utf_8
WIN
UNICODE
windows_1251_to_windows_866
WIN
ALT
windows_1256_to_utf_8
WIN1256
UNICODE
windows_866_to_iso_8859_5
ALT
ISO_8859_5
windows_866_to_koi8_r
ALT
KOI8
windows_866_to_mic
ALT
MULE_INTERNAL
windows_866_to_utf_8
ALT
UNICODE
windows_866_to_windows_1251
ALT
WIN
windows_874_to_utf_8
WIN874
UNICODE
Binary String Functions and Operators
This section describes functions and operators for examining and
manipulating values of type bytea.
SQL defines some string functions with a
special syntax where
certain key words rather than commas are used to separate the
arguments. Details are in
.
Some functions are also implemented using the regular syntax for
function invocation.
(See .)
SQL Binary String Functions and Operators
Function
Return Type
Description
Example
Result
string ||
string
bytea
String concatenation
binary strings
concatenation
'\\\\Post'::bytea || '\\047greSQL\\000'::bytea
\\Post'greSQL\000
octet_length(string)
integer
Number of bytes in binary string
octet_length('jo\\000se'::bytea)
5
position(substring in string)
integer
Location of specified substring
position('\\000om'::bytea in 'Th\\000omas'::bytea)
3
substring(string from integer for integer)
bytea
Extract substring
substring
substring('Th\\000omas'::bytea from 2 for 3)
h\000o
trim(both
bytes from
string)
bytea
Remove the longest string containing only the bytes in
bytes from the start
and end of string
trim('\\000'::bytea from '\\000Tom\\000'::bytea)
Tom
get_byte(string, offset)
integer
Extract byte from string.
get_byte
get_byte('Th\\000omas'::bytea, 4)
109
set_byte(string,
offset, newvalue>)
bytea
Set byte in string.
set_byte
set_byte('Th\\000omas'::bytea, 4, 64)
Th\000o@as
get_bit(string, offset)
integer
Extract bit from string.
get_bit
get_bit('Th\\000omas'::bytea, 45)
1
set_bit(string,
offset, newvalue>)
bytea
Set bit in string.
set_bit
set_bit('Th\\000omas'::bytea, 45, 0)
Th\000omAs
Additional binary string manipulation functions are available and
are listed in . Some
of them are used internally to implement the
SQL-standard string functions listed in .
Other Binary String Functions
Function
Return Type
Description
Example
Result
btrim(string
bytea bytes bytea)
bytea
Remove the longest string consisting only of bytes
in bytes from the start and end of
string.
btrim('\\000trim\\000'::bytea,'\\000'::bytea)
trim
length(string)
integer
Length of binary string
binary strings
length
length
binary strings
binary strings, length
length('jo\\000se'::bytea)
5
decode(string text,
type text)
bytea
Decode binary string from string previously
encoded with encode>. Parameter type is same as in encode>.
decode('123\\000456', 'escape')
123\000456
encode(string bytea,
type text)
text
Encode binary string to ASCII-only representation. Supported
types are: base64>, hex>, escape>.
encode('123\\000456'::bytea, 'escape')
123\000456
Pattern Matching
pattern matching
There are three separate approaches to pattern matching provided by
PostgreSQL: the traditional
SQL
LIKE operator, the more recent
SQL99
SIMILAR TO operator, and
POSIX-style regular expressions.
Additionally, a pattern matching function,
substring, is available, using either
SQL99-style or POSIX-style regular expressions.
If you have pattern matching needs that go beyond this,
consider writing a user-defined function in Perl or Tcl.
LIKE
like
string LIKE pattern ESCAPE escape-character
string NOT LIKE pattern ESCAPE escape-character
Every pattern defines a set of strings.
The LIKE expression returns true if the
string is contained in the set of
strings represented by pattern. (As
expected, the NOT LIKE expression returns
false if LIKE returns true, and vice versa.
An equivalent expression is
NOT (string LIKE
pattern).)
If pattern does not contain percent
signs or underscore, then the pattern only represents the string
itself; in that case LIKE acts like the
equals operator. An underscore (_) in
pattern stands for (matches) any single
character; a percent sign (%) matches any string
of zero or more characters.
Some examples:
'abc' LIKE 'abc' true
'abc' LIKE 'a%' true
'abc' LIKE '_b_' true
'abc' LIKE 'c' false
LIKE pattern matches always cover the entire
string. To match a pattern anywhere within a string, the
pattern must therefore start and end with a percent sign.
To match a literal underscore or percent sign without matching
other characters, the respective character in
pattern must be
preceded by the escape character. The default escape
character is the backslash but a different one may be selected by
using the ESCAPE clause. To match the escape
character itself, write two escape characters.
Note that the backslash already has a special meaning in string
literals, so to write a pattern constant that contains a backslash
you must write two backslashes in an SQL statement. Thus, writing a pattern
that actually matches a literal backslash means writing four backslashes
in the statement. You can avoid this by selecting a different escape
character with ESCAPE; then a backslash is not special
to LIKE anymore. (But it is still special to the string
literal parser, so you still need two of them.)
It's also possible to select no escape character by writing
ESCAPE ''. This effectively disables the
escape mechanism, which makes it impossible to turn off the
special meaning of underscore and percent signs in the pattern.
The key word ILIKE can be used instead of
LIKE to make the match case insensitive according
to the active locale. This is not in the SQL standard but is a
PostgreSQL extension.
The operator ~~ is equivalent to
LIKE, and ~~* corresponds to
ILIKE. There are also
!~~ and !~~* operators that
represent NOT LIKE and NOT
ILIKE, respectively. All of these operators are
PostgreSQL-specific.
SIMILAR TO and SQL99
Regular Expressions
regular expressions
similar to
substring
string SIMILAR TO pattern ESCAPE escape-character
string NOT SIMILAR TO pattern ESCAPE escape-character
The SIMILAR TO operator returns true or false
depending on whether its pattern matches the given string. It is
much like LIKE, except that it interprets the
pattern using SQL99's definition of a regular
expression.
SQL99's regular expressions are a curious cross
between LIKE notation and common regular expression
notation.
Like LIKE, the SIMILAR TO
operator succeeds only if its pattern matches the entire string;
this is unlike common regular expression practice, wherein the pattern
may match any part of the string.
Also like
LIKE, SIMILAR TO uses
_> and %> as wildcard characters denoting
any single character and any string, respectively (these are
comparable to .> and .*> in POSIX regular
expressions).
In addition to these facilities borrowed from LIKE,
SIMILAR TO supports these pattern-matching
metacharacters borrowed from POSIX regular expressions:
| denotes alternation (either of two alternatives).
* denotes repetition of the previous item zero
or more times.
+ denotes repetition of the previous item one
or more times.
Parentheses () may be used to group items into
a single logical item.
A bracket expression [...] specifies a character
class, just as in POSIX regular expressions.
Notice that bounded repetition (?> and {...}>)
are not provided, though they exist in POSIX. Also, the dot (.>)
is not a metacharacter.
As with LIKE>, a backslash disables the special meaning
of any of these metacharacters; or a different escape character can
be specified with ESCAPE>.
Some examples:
'abc' SIMILAR TO 'abc' true
'abc' SIMILAR TO 'a' false
'abc' SIMILAR TO '%(b|d)%' true
'abc' SIMILAR TO '(b|c)%' false
The substring> function with three parameters,
substring(string from
pattern for
escape-character), provides
extraction of a substring that matches a SQL99
regular expression pattern. As with SIMILAR TO>, the
specified pattern must match to the entire data string, else the
function fails and returns null. To indicate the part of the
pattern that should be returned on success, the pattern must contain
two occurrences of the escape character followed by a double quote
(">). The text matching the portion of the pattern
between these markers is returned.
Some examples:
substring('foobar' from '%#"o_b#"%' for '#') oob
substring('foobar' from '#"o_b#"%' for '#') NULL
POSIX Regular Expressions
regular expressions
pattern matching
lists the available
operators for pattern matching using POSIX regular expressions.
Regular Expression Match Operators
Operator
Description
Example
~
Matches regular expression, case sensitive
'thomas' ~ '.*thomas.*'
~*
Matches regular expression, case insensitive
'thomas' ~* '.*Thomas.*'
!~
Does not match regular expression, case sensitive
'thomas' !~ '.*Thomas.*'
!~*
Does not match regular expression, case insensitive
'thomas' !~* '.*vadim.*'
POSIX regular expressions provide a more
powerful means for
pattern matching than the LIKE and
SIMILAR TO> operators.
Many Unix tools such as egrep,
sed, or awk use a pattern
matching language that is similar to the one described here.
A regular expression is a character sequence that is an
abbreviated definition of a set of strings (a regular
set). A string is said to match a regular expression
if it is a member of the regular set described by the regular
expression. As with LIKE, pattern characters
match string characters exactly unless they are special characters
in the regular expression language --- but regular expressions use
different special characters than LIKE does.
Unlike LIKE patterns, a
regular expression is allowed to match anywhere within a string, unless
the regular expression is explicitly anchored to the beginning or
end of the string.
Some examples:
'abc' ~ 'abc' true
'abc' ~ '^a' true
'abc' ~ '(b|d)' true
'abc' ~ '^(b|c)' false
The substring> function with two parameters,
substring(string from
pattern), provides extraction of a substring
that matches a POSIX regular expression pattern. It returns null if
there is no match, otherwise the portion of the text that matched the
pattern. But if the pattern contains any parentheses, the portion
of the text that matched the first parenthesized subexpression (the
one whose left parenthesis comes first) is
returned. You can always put parentheses around the whole expression
if you want to use parentheses within it without triggering this
exception. Also see the non-capturing parentheses described below.
Some examples:
substring('foobar' from 'o.b') oob
substring('foobar' from 'o(.)b') o
PostgreSQL's regular expressions are implemented
using a package written by Henry Spencer. Much of
the description of regular expressions below is copied verbatim from his
manual entry.
Regular Expression Details
Regular expressions (REs), as defined in
POSIX 1003.2, come in two forms:
extended> REs or ERE>s
(roughly those of egrep), and
basic> REs or BRE>s
(roughly those of ed).
PostgreSQL supports both forms, and
also implements some extensions
that are not in the POSIX standard, but have become widely used anyway
due to their availability in programming languages such as Perl and Tcl.
REs using these non-POSIX extensions are called
advanced> REs or ARE>s
in this documentation. AREs are almost an exact superset of EREs,
but BREs have several notational incompatibilities (as well as being
much more limited).
We first describe the ARE and ERE forms, noting features that apply
only to AREs, and then describe how BREs differ.
The form of regular expressions accepted by PostgreSQL>
can be chosen by setting the regex_flavor> run-time parameter
(described in ). The usual setting is
advanced>, but one might choose extended> for
maximum backwards compatibility with pre-7.4 releases of
PostgreSQL>.
A regular expression is defined as one or more
branches, separated by
|. It matches anything that matches one of the
branches.
A branch is zero or more quantified atoms> or
constraints>, concatenated.
It matches a match for the first, followed by a match for the second, etc;
an empty branch matches the empty string.
A quantified atom is an atom> possibly followed
by a single quantifier>.
Without a quantifier, it matches a match for the atom.
With a quantifier, it can match some number of matches of the atom.
An atom can be any of the possibilities
shown in .
The possible quantifiers and their meanings are shown in
.
A constraint> matches an empty string, but matches only when
specific conditions are met. A constraint can be used where an atom
could be used, except it may not be followed by a quantifier.
The simple constraints are shown in
;
some more constraints are described later.
Regular Expression Atoms
Atom
Description
(>re>)>
(where re> is any regular expression)
matches a match for
re>, with the match noted for possible reporting
(?:>re>)>
as above, but the match is not noted for reporting
(a non-capturing> set of parentheses)
(AREs only)
.>
matches any single character
[>chars>]>
a bracket expression>,
matching any one of the chars> (see
for more detail)
\>k>
(where k> is a non-alphanumeric character)
matches that character taken as an ordinary character,
e.g. \\> matches a backslash character
\>c>
where c> is alphanumeric
(possibly followed by other characters)
is an escape>, see
(AREs only; in EREs and BREs, this matches c>)
{>
when followed by a character other than a digit,
matches the left-brace character {>;
when followed by a digit, it is the beginning of a
bound> (see below)
x>
where x> is a single character with no other
significance, matches that character
An RE may not end with \>.
Remember that the backslash (\) already has a special
meaning in PostgreSQL> string literals.
To write a pattern constant that contains a backslash,
you must write two backslashes in the statement.
Regular Expression Quantifiers
Quantifier
Matches
*>
a sequence of 0 or more matches of the atom
+>
a sequence of 1 or more matches of the atom
?>
a sequence of 0 or 1 matches of the atom
{>m>}>
a sequence of exactly m> matches of the atom
{>m>,}>
a sequence of m> or more matches of the atom
{>m>,>n>}>
a sequence of m> through n>
(inclusive) matches of the atom; m> may not exceed
n>
*?>
non-greedy version of *>
+?>
non-greedy version of +>
??>
non-greedy version of ?>
{>m>}?>
non-greedy version of {>m>}>
{>m>,}?>
non-greedy version of {>m>,}>
{>m>,>n>}?>
non-greedy version of {>m>,>n>}>
The forms using {>...>}>
are known as bound>s.
The numbers m> and n> within a bound are
unsigned decimal integers with permissible values from 0 to 255 inclusive.
Non-greedy> quantifiers (available in AREs only) match the
same possibilities as their corresponding normal (greedy>)
counterparts, but prefer the smallest number rather than the largest
number of matches.
See for more detail.
A quantifier cannot immediately follow another quantifier.
A quantifier cannot
begin an expression or subexpression or follow
^ or |.
Regular Expression Constraints
Constraint
Description
^>
matches at the beginning of the string
$>
matches at the end of the string
(?=>re>)>
positive lookahead> matches at any point
where a substring matching re> begins
(AREs only)
(?!>re>)>
negative lookahead> matches at any point
where no substring matching re> begins
(AREs only)
Lookahead constraints may not contain back references>
(see ),
and all parentheses within them are considered non-capturing.
Bracket Expressions
A bracket expression is a list of
characters enclosed in []. It normally matches
any single character from the list (but see below). If the list
begins with ^, it matches any single character
not> from the rest of the list.
If two characters
in the list are separated by -, this is
shorthand for the full range of characters between those two
(inclusive) in the collating sequence,
e.g. [0-9] in ASCII matches
any decimal digit. It is illegal for two ranges to share an
endpoint, e.g. a-c-e. Ranges are very
collating-sequence-dependent, so portable programs should avoid
relying on them.
To include a literal ] in the list, make it the
first character (following a possible ^). To
include a literal -, make it the first or last
character, or the second endpoint of a range. To use a literal
- as the first endpoint of a range, enclose it
in [. and .] to make it a
collating element (see below). With the exception of these characters,
some combinations using [
(see next paragraphs), and escapes (AREs only), all other special
characters lose their special significance within a bracket expression.
In particular, \ is not special when following
ERE or BRE rules, though it is special (as introducing an escape)
in AREs.
Within a bracket expression, a collating element (a character, a
multiple-character sequence that collates as if it were a single
character, or a collating-sequence name for either) enclosed in
[. and .] stands for the
sequence of characters of that collating element. The sequence is
a single element of the bracket expression's list. A bracket
expression containing a multiple-character collating element can thus
match more than one character, e.g. if the collating sequence
includes a ch collating element, then the RE
[[.ch.]]*c matches the first five characters of
chchcc.
PostgreSQL> currently has no multi-character collating
elements. This information describes possible future behavior.
Within a bracket expression, a collating element enclosed in
[= and =] is an equivalence
class, standing for the sequences of characters of all collating
elements equivalent to that one, including itself. (If there are
no other equivalent collating elements, the treatment is as if the
enclosing delimiters were [. and
.].) For example, if o and
^ are the members of an equivalence class, then
[[=o=]], [[=^=]], and
[o^] are all synonymous. An equivalence class
may not be an endpoint of a range.
Within a bracket expression, the name of a character class
enclosed in [: and :] stands
for the list of all characters belonging to that class. Standard
character class names are: alnum,
alpha, blank,
cntrl, digit,
graph, lower,
print, punct,
space, upper,
xdigit. These stand for the character classes
defined in
ctype3.
A locale may provide others. A character class may not be used as
an endpoint of a range.
There are two special cases of bracket expressions: the bracket
expressions [[:<:]] and
[[:>:]] are constraints,
matching empty strings at the beginning
and end of a word respectively. A word is defined as a sequence
of word characters that is neither preceded nor followed by word
characters. A word character is an alnum> character (as
defined by
ctype3)
or an underscore. This is an extension, compatible with but not
specified by POSIX 1003.2, and should be used with
caution in software intended to be portable to other systems.
The constraint escapes described below are usually preferable (they
are no more standard, but are certainly easier to type).
Regular Expression Escapes
Escapes> are special sequences beginning with \>
followed by an alphanumeric character. Escapes come in several varieties:
character entry, class shorthands, constraint escapes, and back references.
A \> followed by an alphanumeric character but not constituting
a valid escape is illegal in AREs.
In EREs, there are no escapes: outside a bracket expression,
a \> followed by an alphanumeric character merely stands for
that character as an ordinary character, and inside a bracket expression,
\> is an ordinary character.
(The latter is the one actual incompatibility between EREs and AREs.)
Character-entry escapes> exist to make it easier to specify
non-printing and otherwise inconvenient characters in REs. They are
shown in .
Class-shorthand escapes> provide shorthands for certain
commonly-used character classes. They are
shown in .
A constraint escape> is a constraint,
matching the empty string if specific conditions are met,
written as an escape. They are
shown in .
A back reference> (\>n>) matches the
same string matched by the previous parenthesized subexpression specified
by the number n>
(see ). For example,
([bc])\1> matches bb> or cc>
but not bc> or cb>.
The subexpression must entirely precede the back reference in the RE.
Subexpressions are numbered in the order of their leading parentheses.
Non-capturing parentheses do not define subexpressions.
Keep in mind that an escape's leading \> will need to be
doubled when entering the pattern as an SQL string constant.
Regular Expression Character-Entry Escapes
Escape
Description
\a>
alert (bell) character, as in C
\b>
backspace, as in C
\B>
synonym for \> to help reduce the need for backslash
doubling
\c>X>
(where X> is any character) the character whose
low-order 5 bits are the same as those of
X>, and whose other bits are all zero
\e>
the character whose collating-sequence name
is ESC>,
or failing that, the character with octal value 033
\f>
formfeed, as in C
\n>
newline, as in C
\r>
carriage return, as in C
\t>
horizontal tab, as in C
\u>wxyz>
(where wxyz> is exactly four hexadecimal digits)
the Unicode character U+>wxyz>
in the local byte ordering
\U>stuvwxyz>
(where stuvwxyz> is exactly eight hexadecimal
digits)
reserved for a somewhat-hypothetical Unicode extension to 32 bits
\v>
vertical tab, as in C
\x>hhh>
(where hhh> is any sequence of hexadecimal
digits)
the character whose hexadecimal value is
0x>hhh>
(a single character no matter how many hexadecimal digits are used)
\0>
the character whose value is 0>
\>xy>
(where xy> is exactly two octal digits,
and is not a back reference>)
the character whose octal value is
0>xy>
\>xyz>
(where xyz> is exactly three octal digits,
and is not a back reference>)
the character whose octal value is
0>xyz>
Hexadecimal digits are 0>-9>,
a>-f>, and A>-F>.
Octal digits are 0>-7>.
The character-entry escapes are always taken as ordinary characters.
For example, \135> is ]> in ASCII, but
\135> does not terminate a bracket expression.
Regular Expression Class-Shorthand Escapes
Escape
Description
\d>
[[:digit:]]>
\s>
[[:space:]]>
\w>
[[:alnum:]_]>
(note underscore is included)
\D>
[^[:digit:]]>
\S>
[^[:space:]]>
\W>
[^[:alnum:]_]>
(note underscore is included)
Within bracket expressions, \d>, \s>,
and \w> lose their outer brackets,
and \D>, \S>, and \W> are illegal.
(So, for example, [a-c\d]> is equivalent to
[a-c[:digit:]]>.
Also, [a-c\D]>, which is equivalent to
[a-c^[:digit:]]>, is illegal.)
Regular Expression Constraint Escapes
Escape
Description
\A>
matches only at the beginning of the string
(see for how this differs from
^>)
\m>
matches only at the beginning of a word
\M>
matches only at the end of a word
\y>
matches only at the beginning or end of a word
\Y>
matches only at a point that is not the beginning or end of a
word
\Z>
matches only at the end of the string
(see for how this differs from
$>)
A word is defined as in the specification of
[[:<:]]> and [[:>:]]> above.
Constraint escapes are illegal within bracket expressions.
Regular Expression Back References
Escape
Description
\>m>
(where m> is a nonzero digit)
a back reference to the m>'th subexpression
\>mnn>
(where m> is a nonzero digit, and
nn> is some more digits, and the decimal value
mnn> is not greater than the number of closing capturing
parentheses seen so far)
a back reference to the mnn>'th subexpression
There is an inherent historical ambiguity between octal character-entry
escapes and back references, which is resolved by heuristics,
as hinted at above.
A leading zero always indicates an octal escape.
A single non-zero digit, not followed by another digit,
is always taken as a back reference.
A multi-digit sequence not starting with a zero is taken as a back
reference if it comes after a suitable subexpression
(i.e. the number is in the legal range for a back reference),
and otherwise is taken as octal.
Regular Expression Metasyntax
In addition to the main syntax described above, there are some special
forms and miscellaneous syntactic facilities available.
Normally the flavor of RE being used is determined by
REGEX_FLAVOR>.
However, this can be overridden by a director> prefix.
If an RE of any flavor begins with ***:>,
the rest of the RE is taken as an ARE.
If an RE of any flavor begins with ***=>,
the rest of the RE is taken to be a literal string,
with all characters considered ordinary characters.
An ARE may begin with embedded options>:
a sequence (?>xyz>)>
(where xyz> is one or more alphabetic characters)
specifies options affecting the rest of the RE.
These options override any previously determined options (including
both the RE flavor and case sensitivity).
The available option letters are
shown in .
ARE Embedded-Option Letters
Option
Description
b>
rest of RE is a BRE
c>
case-sensitive matching (overrides operator type)
e>
rest of RE is an ERE
i>
case-insensitive matching (see
) (overrides operator type)
m>
historical synonym for n>
n>
newline-sensitive matching (see
)
p>
partial newline-sensitive matching (see
)
q>
rest of RE is a literal (quoted>) string, all ordinary
characters
s>
non-newline-sensitive matching (default)
t>
tight syntax (default; see below)
w>
inverse partial newline-sensitive (weird>) matching
(see )
x>
expanded syntax (see below)
Embedded options take effect at the )> terminating the sequence.
They are available only at the start of an ARE,
and may not be used later within it.
In addition to the usual (tight>) RE syntax, in which all
characters are significant, there is an expanded> syntax,
available by specifying the embedded x> option.
In the expanded syntax,
white-space characters in the RE are ignored, as are
all characters between a #>
and the following newline (or the end of the RE). This
permits paragraphing and commenting a complex RE.
There are three exceptions to that basic rule:
a white-space character or #> preceded by \> is
retained
white space or #> within a bracket expression is retained
white space and comments are illegal within multi-character symbols,
like the ARE (?:> or the BRE \(>
Expanded-syntax white-space characters are blank, tab, newline, and
any character that belongs to the space> character class.
Finally, in an ARE, outside bracket expressions, the sequence
(?#>ttt>)>
(where ttt> is any text not containing a )>)
is a comment, completely ignored.
Again, this is not allowed between the characters of
multi-character symbols, like (?:>.
Such comments are more a historical artifact than a useful facility,
and their use is deprecated; use the expanded syntax instead.
None> of these metasyntax extensions is available if
an initial ***=> director
has specified that the user's input be treated as a literal string
rather than as an RE.
Regular Expression Matching Rules
In the event that an RE could match more than one substring of a given
string, the RE matches the one starting earliest in the string.
If the RE could match more than one substring starting at that point,
its choice is determined by its preference>:
either the longest substring, or the shortest.
Most atoms, and all constraints, have no preference.
A parenthesized RE has the same preference (possibly none) as the RE.
A quantified atom with quantifier
{>m>}>
or
{>m>}?>
has the same preference (possibly none) as the atom itself.
A quantified atom with other normal quantifiers (including
{>m>,>n>}>
with m> equal to n>)
prefers longest match.
A quantified atom with other non-greedy quantifiers (including
{>m>,>n>}?>
with m> equal to n>)
prefers shortest match.
A branch has the same preference as the first quantified atom in it
which has a preference.
An RE consisting of two or more branches connected by the
|> operator prefers longest match.
Subject to the constraints imposed by the rules for matching the whole RE,
subexpressions also match the longest or shortest possible substrings,
based on their preferences,
with subexpressions starting earlier in the RE taking priority over
ones starting later.
Note that outer subexpressions thus take priority over
their component subexpressions.
The quantifiers {1,1}> and {1,1}?>
can be used to force longest and shortest preference, respectively,
on a subexpression or a whole RE.
Match lengths are measured in characters, not collating elements.
An empty string is considered longer than no match at all.
For example:
bb*>
matches the three middle characters of abbbc>;
(week|wee)(night|knights)>
matches all ten characters of weeknights>;
when (.*).*>
is matched against abc> the parenthesized subexpression
matches all three characters; and when
(a*)*> is matched against bc>
both the whole RE and the parenthesized
subexpression match an empty string.
If case-independent matching is specified,
the effect is much as if all case distinctions had vanished from the
alphabet.
When an alphabetic that exists in multiple cases appears as an
ordinary character outside a bracket expression, it is effectively
transformed into a bracket expression containing both cases,
e.g. x> becomes [xX]>.
When it appears inside a bracket expression, all case counterparts
of it are added to the bracket expression, e.g.
[x]> becomes [xX]>
and [^x]> becomes [^xX]>.
If newline-sensitive matching is specified, .>
and bracket expressions using ^>
will never match the newline character
(so that matches will never cross newlines unless the RE
explicitly arranges it)
and ^>and $>
will match the empty string after and before a newline
respectively, in addition to matching at beginning and end of string
respectively.
But the ARE escapes \A> and \Z>
continue to match beginning or end of string only>.
If partial newline-sensitive matching is specified,
this affects .> and bracket expressions
as with newline-sensitive matching, but not ^>
and $>.
If inverse partial newline-sensitive matching is specified,
this affects ^> and $>
as with newline-sensitive matching, but not .>
and bracket expressions.
This isn't very useful but is provided for symmetry.
Limits and Compatibility
No particular limit is imposed on the length of REs in this
implementation. However,
programs intended to be highly portable should not employ REs longer
than 256 bytes,
as a POSIX-compliant implementation can refuse to accept such REs.
The only feature of AREs that is actually incompatible with
POSIX EREs is that \> does not lose its special
significance inside bracket expressions.
All other ARE features use syntax which is illegal or has
undefined or unspecified effects in POSIX EREs;
the ***> syntax of directors likewise is outside the POSIX
syntax for both BREs and EREs.
Many of the ARE extensions are borrowed from Perl, but some have
been changed to clean them up, and a few Perl extensions are not present.
Incompatibilities of note include \b>, \B>,
the lack of special treatment for a trailing newline,
the addition of complemented bracket expressions to the things
affected by newline-sensitive matching,
the restrictions on parentheses and back references in lookahead
constraints, and the longest/shortest-match (rather than first-match)
matching semantics.
Two significant incompatibilities exist between AREs and the ERE syntax
recognized by pre-7.4 releases of PostgreSQL>:
In AREs, \> followed by an alphanumeric character is either
an escape or an error, while in previous releases, it was just another
way of writing the alphanumeric.
This should not be much of a problem because there was no reason to
write such a sequence in earlier releases.
In AREs, \> remains a special character within
[]>, so a literal \> within a bracket
expression must be written \\>.
While these differences are unlikely to create a problem for most
applications, you can avoid them if necessary by
setting REGEX_FLAVOR> to extended>.
Basic Regular Expressions
BREs differ from EREs in several respects.
|>, +>, and ?>
are ordinary characters and there is no equivalent
for their functionality.
The delimiters for bounds are
\{> and \}>,
with {> and }>
by themselves ordinary characters.
The parentheses for nested subexpressions are
\(> and \)>,
with (> and )> by themselves ordinary characters.
^> is an ordinary character except at the beginning of the
RE or the beginning of a parenthesized subexpression,
$> is an ordinary character except at the end of the
RE or the end of a parenthesized subexpression,
and *> is an ordinary character if it appears at the beginning
of the RE or the beginning of a parenthesized subexpression
(after a possible leading ^>).
Finally, single-digit back references are available, and
\<> and \>>
are synonyms for
[[:<:]]> and [[:>:]]>
respectively; no other escapes are available.
Data Type Formatting Functions
formatting
The PostgreSQL formatting functions
provide a powerful set of tools for converting various data types
(date/time, integer, floating point, numeric) to formatted strings
and for converting from formatted strings to specific data types.
lists them.
These functions all follow a common calling convention: the first
argument is the value to be formatted and the second argument is a
template that defines the output or input format.
In an output template string (for to_char>), there are certain patterns that are
recognized and replaced with appropriately-formatted data from the value
to be formatted. Any text that is not a template pattern is simply
copied verbatim. Similarly, in an input template string (for anything but to_char>), template patterns
identify the parts of the input data string to be looked at and the
values to be found there.
shows the
template patterns available for formatting date and time values.
Certain modifiers may be applied to any template pattern to alter its
behavior. For example, FMMonth
is the Month pattern with the
FM modifier.
shows the
modifier patterns for date/time formatting.
Usage notes for the date/time formatting:
FM suppresses leading zeroes and trailing blanks
that would otherwise be added to make the output of a pattern be
fixed-width.
to_timestamp and to_date
skip multiple blank spaces in the input string if the FX option
is not used. FX must be specified as the first item
in the template. For example
to_timestamp('2000 JUN', 'YYYY MON') is correct, but
to_timestamp('2000 JUN', 'FXYYYY MON') returns an error,
because to_timestamp expects one space only.
Ordinary text is allowed in to_char
templates and will be output literally. You can put a substring
in double quotes to force it to be interpreted as literal text
even if it contains pattern key words. For example, in
'"Hello Year "YYYY', the YYYY
will be replaced by the year data, but the single Y in Year
will not be.
If you want to have a double quote in the output you must
precede it with a backslash, for example '\\"YYYY
Month\\"'.
(Two backslashes are necessary because the backslash already
has a special meaning in a string constant.)
The YYYY conversion from string to timestamp or
date has a restriction if you use a year with more than 4 digits. You must
use some non-digit character or template after YYYY,
otherwise the year is always interpreted as 4 digits. For example
(with the year 20000):
to_date('200001131', 'YYYYMMDD') will be
interpreted as a 4-digit year; instead use a non-digit
separator after the year, like
to_date('20000-1131', 'YYYY-MMDD') or
to_date('20000Nov31', 'YYYYMonDD').
Millisecond (MS) and microsecond (US)
values in a conversion from string to timestamp are used as part of the
seconds after the decimal point. For example
to_timestamp('12:3', 'SS:MS') is not 3 milliseconds,
but 300, because the conversion counts it as 12 + 0.3 seconds.
This means for the format SS:MS, the input values
12:3, 12:30, and 12:300 specify the
same number of milliseconds. To get three milliseconds, one must use
12:003, which the conversion counts as
12 + 0.003 = 12.003 seconds.
Here is a more
complex example:
to_timestamp('15:12:02.020.001230', 'HH:MI:SS.MS.US')
is 15 hours, 12 minutes, and 2 seconds + 20 milliseconds +
1230 microseconds = 2.021230 seconds.
shows the
template patterns available for formatting numeric values.
Usage notes for the numeric formatting:
A sign formatted using SG, PL, or
MI is not anchored to
the number; for example,
to_char(-12, 'S9999') produces ' -12',
but to_char(-12, 'MI9999') produces '- 12'.
The Oracle implementation does not allow the use of
MI ahead of 9, but rather
requires that 9 precede
MI.
9 results in a value with the same number of
digits as there are 9s. If a digit is
not available it outputs a space.
TH does not convert values less than zero
and does not convert fractional numbers.
PL, SG, and
TH are PostgreSQL
extensions.
V effectively
multiplies the input values by
10^n, where
n is the number of digits following
V.
to_char does not support the use of
V combined with a decimal point.
(E.g., 99.9V99 is not allowed.)
shows some
examples of the use of the to_char function.
Date/Time Functions and Operators
shows the available
functions for date/time value processing, with details appearing in
the following subsections. illustrates the behaviors of
the basic arithmetic operators (+,
*, etc.). For formatting functions, refer to
. You should be familiar with
the background information on date/time data types from .
All the functions and operators described below that take time or timestamp
inputs actually come in two variants: one that takes time with time zone or timestamp
with time zone, and one that takes time without time zone or timestamp without time zone.
For brevity, these variants are not shown separately.
Date/Time Operators
Operator
Example
Result
+
timestamp '2001-09-28 01:00' + interval '23 hours'
timestamp '2001-09-29 00:00'
+
date '2001-09-28' + interval '1 hour'
timestamp '2001-09-28 01:00'
+
time '01:00' + interval '3 hours'
time '04:00'
-
timestamp '2001-09-28 23:00' - interval '23 hours'
timestamp '2001-09-28'
-
date '2001-09-28' - interval '1 hour'
timestamp '2001-09-27 23:00'
-
time '05:00' - interval '2 hours'
time '03:00'
-
interval '2 hours' - time '05:00'
time '03:00:00'
*
interval '1 hour' * int '3'
interval '03:00'
/
interval '1 hour' / int '3'
interval '00:20'
Date/Time Functions
Function
Return Type
Description
Example
Result
age(timestamp)
interval
Subtract from today
age(timestamp '1957-06-13')
43 years 8 mons 3 days
age(timestamp, timestamp)
interval
Subtract arguments
age('2001-04-10', timestamp '1957-06-13')
43 years 9 mons 27 days
current_date
date
Today's date; see
current_time
time with time zone
Time of day; see
current_timestamp
timestamp with time zone
Date and time; see
date_part(text, timestamp)
double precision
Get subfield (equivalent to
extract); see
date_part('hour', timestamp '2001-02-16 20:38:40')
20
date_part(text, interval)
double precision
Get subfield (equivalent to
extract); see
date_part('month', interval '2 years 3 months')
3
date_trunc(text, timestamp)
timestamp
Truncate to specified precision; see also
date_trunc('hour', timestamp '2001-02-16 20:38:40')
2001-02-16 20:00:00+00
extract(field from
timestamp)
double precision
Get subfield; see
extract(hour from timestamp '2001-02-16 20:38:40')
20
extract(field from
interval)
double precision
Get subfield; see
extract(month from interval '2 years 3 months')
3
isfinite(timestamp)
boolean
Test for finite time stamp (not equal to infinity)
isfinite(timestamp '2001-02-16 21:28:30')
true
isfinite(interval)
boolean
Test for finite interval
isfinite(interval '4 hours')
true
localtime
time
Time of day; see
localtimestamp
timestamp
Date and time; see
now()
timestamp with time zone
Current date and time (equivalent to
current_timestamp); see
timeofday()
text
Current date and time; see
timeofday()
Wed Feb 21 17:01:13.000126 2001 EST
date_trunc
The function date_trunc is conceptually
similar to the trunc function for numbers.
date_trunc('field', source)
source is a value expression of type
timestamp. (Values of type date and
time are cast automatically.)
field selects to which precision to
truncate the time stamp value. The return value is of type
timestamp with all fields that are less than the
selected one set to zero (or one, for day and month).
Valid values for field are:
microseconds
milliseconds
second
minute
hour
day
month
year
decade
century
millennium
Examples:
SELECT date_trunc('hour', TIMESTAMP '2001-02-16 20:38:40');
Result: 2001-02-16 20:00:00+00
SELECT date_trunc('year', TIMESTAMP '2001-02-16 20:38:40');
Result: 2001-01-01 00:00:00+00
AT TIME ZONE
time zone
conversion
The AT TIME ZONE construct allows conversions
of time stamps to different time zones. shows its
variants.
AT TIME ZONE Variants
Expression
Return Type
Description
timestamp without time zone AT TIME ZONE zone>
timestamp with time zone
Convert local time in given time zone to UTC
timestamp with time zone AT TIME ZONE zone>
timestamp without time zone
Convert UTC to local time in given time zone
time with time zone AT TIME ZONE zone>
time with time zone
Convert local time across time zones
In these expressions, the desired time zone zone> can be
specified either as a text string (e.g., 'PST')
or as an interval (e.g., INTERVAL '-08:00').
Examples (supposing that the local time zone is PST8PDT>):
SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'MST';
Result: 2001-02-16 19:38:40-08
SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT TIME ZONE 'MST';
Result: 2001-02-16 18:38:40
The first example takes a zone-less time stamp and interprets it as MST time
(UTC-7) to produce a UTC time stamp, which is then rotated to PST (UTC-8)
for display. The second example takes a time stamp specified in EST
(UTC-5) and converts it to local time in MST (UTC-7).
The function timezone(zone>,
timestamp>) is equivalent to the SQL-conforming construct
timestamp> AT TIME ZONE
zone>.
Current Date/Time
date
current
time
current
The following functions are available to obtain the current date and/or
time:
CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP
CURRENT_TIME ( precision )
CURRENT_TIMESTAMP ( precision )
LOCALTIME
LOCALTIMESTAMP
LOCALTIME ( precision )
LOCALTIMESTAMP ( precision )
CURRENT_TIME and
CURRENT_TIMESTAMP deliver values with time zone;
LOCALTIME and
LOCALTIMESTAMP deliver values without time zone.
CURRENT_TIME,
CURRENT_TIMESTAMP,
LOCALTIME, and
LOCALTIMESTAMP
can optionally be given
a precision parameter, which causes the result to be rounded
to that many fractional digits in the seconds field. Without a precision parameter,
the result is given to the full available precision.
Prior to PostgreSQL 7.2, the precision
parameters were unimplemented, and the result was always given
in integer seconds.
Some examples:
SELECT CURRENT_TIME;
Result: 14:39:53.662522-05
SELECT CURRENT_DATE;
Result: 2001-12-23
SELECT CURRENT_TIMESTAMP;
Result: 2001-12-23 14:39:53.662522-05
SELECT CURRENT_TIMESTAMP(2);
Result: 2001-12-23 14:39:53.66-05
SELECT LOCALTIMESTAMP;
Result: 2001-12-23 14:39:53.662522
The function now() is the traditional
PostgreSQL equivalent to
CURRENT_TIMESTAMP.
There is also the function timeofday(), which for historical
reasons returns a text string rather than a timestamp value:
SELECT timeofday();
Result: Sat Feb 17 19:07:32.000126 2001 EST
It is important to know that
CURRENT_TIMESTAMP and related functions return
the start time of the current transaction; their values do not
change during the transaction. This is considered a feature:
the intent is to allow a single transaction to have a consistent
notion of the current
time, so that multiple
modifications within the same transaction bear the same
timestamp. timeofday()
returns the wall-clock time and does advance during transactions.
Other database systems may advance these values more
frequently.
All the date/time data types also accept the special literal value
now to specify the current date and time. Thus,
the following three all return the same result:
SELECT CURRENT_TIMESTAMP;
SELECT now();
SELECT TIMESTAMP 'now';
You do not want to use the third form when specifying a DEFAULT>
clause while creating a table. The system will convert now
to a timestamp as soon as the constant is parsed, so that when
the default value is needed,
the time of the table creation would be used! The first two
forms will not be evaluated until the default value is used,
because they are function calls. Thus they will give the desired
behavior of defaulting to the time of row insertion.
Geometric Functions and Operators
The geometric types point, box,
lseg, line, path,
polygon, and circle have a large set of
native support functions and operators, shown in , , and .
Geometric Operators
Operator
Description
Example
+
Translation
box '((0,0),(1,1))' + point '(2.0,0)'
-
Translation
box '((0,0),(1,1))' - point '(2.0,0)'
*
Scaling/rotation
box '((0,0),(1,1))' * point '(2.0,0)'
/
Scaling/rotation
box '((0,0),(2,2))' / point '(2.0,0)'
#
Point or box of intersection
'((1,-1),(-1,1))' # '((1,1),(-1,-1))'
#
Number of points in path or polygon
# '((1,0),(0,1),(-1,0))'
@-@
Length or circumference
@-@ path '((0,0),(1,0))'
@@
Center
@@ circle '((0,0),10)'
##
Closest point to first operand on second operand
point '(0,0)' ## lseg '((2,0),(0,2))'
<->
Distance between
circle '((0,0),1)' <-> circle '((5,0),1)'
&&
Overlaps?
box '((0,0),(1,1))' && box '((0,0),(2,2))'
&<
Overlaps or is left of?
box '((0,0),(1,1))' &< box '((0,0),(2,2))'
&>
Overlaps or is right of?
box '((0,0),(3,3))' &> box '((0,0),(2,2))'
<<
Is left of?
circle '((0,0),1)' << circle '((5,0),1)'
>>
Is right of?
circle '((5,0),1)' >> circle '((0,0),1)'
<^
Is below?
circle '((0,0),1)' <^ circle '((0,5),1)'
>^
Is above?
circle '((0,5),1)' >^ circle '((0,0),1)'
?#
Intersects?
lseg '((-1,0),(1,0))' ?# box '((-2,-2),(2,2))'
?-
Is horizontal?
?- lseg '((-1,0),(1,0))'
?-
Are horizontally aligned?
point '(1,0)' ?- point '(0,0)'
?|
Is vertical?
?| lseg '((-1,0),(1,0))'
?|
Are vertically aligned?
point '(0,1)' ?| point '(0,0)'
?-|
Is perpendicular?
lseg '((0,0),(0,1))' ?-| lseg '((0,0),(1,0))'
?||
Are parallel?
lseg '((-1,0),(1,0))' ?|| lseg '((-1,2),(1,2))'
~
Contains?
circle '((0,0),2)' ~ point '(1,1)'
@
Contained in or on?
point '(1,1)' @ circle '((0,0),2)'
~=
Same as?
polygon '((0,0),(1,1))' ~= polygon '((1,1),(0,0))'
Geometric Functions
Function
Return Type
Description
Example
area(object>)
double precision
area
area(box '((0,0),(1,1))')
box_intersect(box>, box>)
box
intersection box
box_intersect(box '((0,0),(1,1))',box '((0.5,0.5),(2,2))')
center(object>)
point
center
center(box '((0,0),(1,2))')
diameter(circle>)
double precision
diameter of circle
diameter(circle '((0,0),2.0)')
height(box>)
double precision
vertical size of box
height(box '((0,0),(1,1))')
isclosed(path>)
boolean
a closed path?
isclosed(path '((0,0),(1,1),(2,0))')
isopen(path>)
boolean
an open path?
isopen(path '[(0,0),(1,1),(2,0)]')
length(object>)
double precision
length
length(path '((-1,0),(1,0))')
npoints(path>)
integer
number of points
npoints(path '[(0,0),(1,1),(2,0)]')
npoints(polygon>)
integer
number of points
npoints(polygon '((1,1),(0,0))')
pclose(path>)
path
convert path to closed
popen(path '[(0,0),(1,1),(2,0)]')
point(lseg>, lseg>)
point
intersection
point(lseg '((-1,0),(1,0))',lseg '((-2,-2),(2,2))')
]]>
popen(path>)
path
convert path to open
popen(path '((0,0),(1,1),(2,0))')
radius(circle)
double precision
radius of circle
radius(circle '((0,0),2.0)')
width(box>)
double precision
horizontal size of box
width(box '((0,0),(1,1))')
Geometric Type Conversion Functions
Function
Return Type
Description
Example
box(circle)
box
circle to box
box(circle '((0,0),2.0)')
box(point, point)
box
points to box
box(point '(0,0)', point '(1,1)')
box(polygon)
box
polygon to box
box(polygon '((0,0),(1,1),(2,0))')
circle(box)
circle
box to circle
circle(box '((0,0),(1,1))')
circle(point, double precision)
circle
point and radius to circle
circle(point '(0,0)', 2.0)
lseg(box)
lseg
box diagonal to line segment
lseg(box '((-1,0),(1,0))')
lseg(point, point)
lseg
points to line segment
lseg(point '(-1,0)', point '(1,0)')
path(polygon)
point
polygon to path
path(polygon '((0,0),(1,1),(2,0))')
point(circle)
point
center of circle
point(circle '((0,0),2.0)')
point(lseg, lseg)
point
intersection
point(lseg '((-1,0),(1,0))', lseg '((-2,-2),(2,2))')
point(polygon)
point
center of polygon
point(polygon '((0,0),(1,1),(2,0))')
polygon(box)
polygon
box to 4-point polygon
polygon(box '((0,0),(1,1))')
polygon(circle)
polygon
circle to 12-point polygon
polygon(circle '((0,0),2.0)')
polygon(npts, circle)
polygon
circle to npts-point polygon
polygon(12, circle '((0,0),2.0)')
polygon(path)
polygon
path to polygon
polygon(path '((0,0),(1,1),(2,0))')
It is possible to access the two component numbers of a point>
as though it were an array with indices 0 and 1. For example, if
t.p> is a point> column then
SELECT p[0] FROM t> retrieves the X coordinate and
UPDATE t SET p[1] = ...> changes the Y coordinate.
In the same way, a value of type box> or lseg> may be treated
as an array of two point> values.
Network Address Type Functions
shows the operators
available for the cidr and inet types.
The operators <<,
<<=, >>, and
>>= test for subnet inclusion. They
consider only the network parts of the two addresses, ignoring any
host part, and determine whether one network part is identical to
or a subnet of the other.
cidr and inet Operators
Operator
Description
Example
<
is less than
inet '192.168.1.5' < inet '192.168.1.6'
<=
is less than or equal
inet '192.168.1.5' <= inet '192.168.1.5'
=
equals
inet '192.168.1.5' = inet '192.168.1.5'
>=
is greater or equal
inet '192.168.1.5' >= inet '192.168.1.5'
>
is greater than
inet '192.168.1.5' > inet '192.168.1.4'
<>
is not equal
inet '192.168.1.5' <> inet '192.168.1.4'
<<
is contained within
inet '192.168.1.5' << inet '192.168.1/24'
<<=
is contained within or equals
inet '192.168.1/24' <<= inet '192.168.1/24'
>>
contains
inet'192.168.1/24' >> inet '192.168.1.5'
>>=
contains or equals
inet '192.168.1/24' >>= inet '192.168.1/24'
shows the functions
available for use with the cidr and inet
types. The host,
text, and abbrev
functions are primarily intended to offer alternative display
formats. You can cast a text value to inet> using normal casting
syntax: inet(expression>) or
colname>::inet.
cidr and inet Functions
Function
Return Type
Description
Example
Result
broadcast(inet)
inet
broadcast address for network
broadcast('192.168.1.5/24')
192.168.1.255/24
host(inet)
text
extract IP address as text
host('192.168.1.5/24')
192.168.1.5
masklen(inet)
integer
extract netmask length
masklen('192.168.1.5/24')
24
set_masklen(inet,integer)
inet
set netmask length for inet value
set_masklen('192.168.1.5/24',16)
192.168.1.5/16
netmask(inet)
inet
construct netmask for network
netmask('192.168.1.5/24')
255.255.255.0
hostmask(inet)
inet
construct hostmask for network
hostmask('192.168.23.20/30')
0.0.0.3
network(inet)
cidr
extract network part of address
network('192.168.1.5/24')
192.168.1.0/24
text(inet)
text
extract IP address and netmask length as text
text(inet '192.168.1.5')
192.168.1.5/32
abbrev(inet)
text
abbreviated display format as text
abbrev(cidr '10.1.0.0/16')
10.1/16
shows the functions
available for use with the macaddr type. The function
trunc(macaddr) returns a MAC
address with the last 3 bytes set to zero. This can be used to
associate the remaining prefix with a manufacturer. The directory
contrib/mac in the source distribution
contains some utilities to create and maintain such an association
table.
macaddr Functions
Function
Return Type
Description
Example
Result
trunc(macaddr)
macaddr
set last 3 bytes to zero
trunc(macaddr '12:34:56:78:90:ab')
12:34:56:00:00:00
The macaddr type also supports the standard relational
operators (>, <=, etc.) for
lexicographical ordering.
Sequence-Manipulation Functions
sequences
nextval
currval
setval
This section describes PostgreSQL's functions
for operating on sequence objects.
Sequence objects (also called sequence generators or
just sequences) are special single-row tables created with
CREATE SEQUENCE. A sequence object is usually used to
generate unique identifiers for rows of a table. The sequence functions,
listed in ,
provide simple, multiuser-safe methods for obtaining successive
sequence values from sequence objects.
Sequence Functions
Function Return Type Description
nextval(text)
bigint
Advance sequence and return new value
currval(text)
bigint
Return value most recently obtained with nextval
setval(text, bigint)
bigint
Set sequence's current value
setval(text, bigint, boolean)
bigint
Set sequence's current value and is_called flag
For largely historical reasons, the sequence to be operated on by a
sequence-function call is specified by a text-string argument. To
achieve some compatibility with the handling of ordinary
SQL names, the sequence functions convert their
argument to lower case unless the string is double-quoted. Thus
nextval('foo') operates on sequence foo>
nextval('FOO') operates on sequence foo>
nextval('"Foo"') operates on sequence Foo>
The sequence name can be schema-qualified if necessary:
nextval('myschema.foo') operates on myschema.foo>
nextval('"myschema".foo') same as above
nextval('foo') searches search path for foo>
Of course, the text argument can be the result of an expression,
not only a simple literal, which is occasionally useful.
The available sequence functions are:
nextval
Advance the sequence object to its next value and return that
value. This is done atomically: even if multiple sessions
execute nextval concurrently, each will safely receive
a distinct sequence value.
currval
Return the value most recently obtained by nextval
for this sequence in the current session. (An error is
reported if nextval has never been called for this
sequence in this session.) Notice that because this is returning
a session-local value, it gives a predictable answer even if other
sessions are executing nextval meanwhile.
setval
Reset the sequence object's counter value. The two-parameter
form sets the sequence's last_value field to the specified
value and sets its is_called field to true,
meaning that the next nextval will advance the sequence
before returning a value. In the three-parameter form,
is_called may be set either true or
false. If it's set to false,
the next nextval will return exactly the specified
value, and sequence advancement commences with the following
nextval. For example,
SELECT setval('foo', 42); Next nextval> will return 43
SELECT setval('foo', 42, true); Same as above
SELECT setval('foo', 42, false); Next nextval> will return 42
The result returned by setval is just the value of its
second argument.
To avoid blocking of concurrent transactions that obtain numbers from the
same sequence, a nextval operation is never rolled back;
that is, once a value has been fetched it is considered used, even if the
transaction that did the nextval later aborts. This means
that aborted transactions may leave unused holes
in the
sequence of assigned values. setval operations are never
rolled back, either.
If a sequence object has been created with default parameters,
nextval calls on it will return successive values
beginning with 1. Other behaviors can be obtained by using
special parameters in the command;
see its command reference page for more information.
Conditional Expressions
case
conditionals
This section describes the SQL-compliant conditional expressions
available in PostgreSQL.
If your needs go beyond the capabilities of these conditional
expressions you might want to consider writing a stored procedure
in a more expressive programming language.
CASE>
The SQL CASE expression is a
generic conditional expression, similar to if/else statements in
other languages:
CASE WHEN condition THEN result
WHEN ...
ELSE result
END
CASE clauses can be used wherever
an expression is valid. condition is an
expression that returns a boolean result. If the result is true
then the value of the CASE expression is the
result that follows the condition. If the result is false any
subsequent WHEN clauses are searched in the same
manner. If no WHEN
condition is true then the value of the
case expression is the result in the
ELSE clause. If the ELSE clause is
omitted and no condition matches, the result is null.
An example:
SELECT * FROM test;
a
---
1
2
3
SELECT a,
CASE WHEN a=1 THEN 'one'
WHEN a=2 THEN 'two'
ELSE 'other'
END
FROM test;
a | case
---+-------
1 | one
2 | two
3 | other
The data types of all the result
expressions must be convertible to a single output type.
See for more detail.
The following simple
CASE expression is a
specialized variant of the general form above:
CASE expression
WHEN value THEN result
WHEN ...
ELSE result
END
The
expression is computed and compared to
all the value specifications in the
WHEN clauses until one is found that is equal. If
no match is found, the result in the
ELSE clause (or a null value) is returned. This is similar
to the switch statement in C.
The example above can be written using the simple
CASE syntax:
SELECT a,
CASE a WHEN 1 THEN 'one'
WHEN 2 THEN 'two'
ELSE 'other'
END
FROM test;
a | case
---+-------
1 | one
2 | two
3 | other
COALESCE>
COALESCE(value , ...)
The COALESCE function returns the first of its
arguments that is not null. This is often useful to substitute a
default value for null values when data is retrieved for display,
for example:
SELECT COALESCE(description, short_description, '(none)') ...
NULLIF>
nullif
NULLIF(value1, value2)
The NULLIF function returns a null value if and only
if value1 and
value2 are equal. Otherwise it returns
value1. This can be used to perform the
inverse operation of the COALESCE example
given above:
SELECT NULLIF(value, '(none)') ...
Miscellaneous Functions
shows several
functions that extract session and system information.
Session Information Functions
Name Return Type Description
current_database()
name
name of current database
current_schema()
name
name of current schema
current_schemas(boolean)
name[]
names of schemas in search path optionally including implicit schemas
current_user
name
user name of current execution context
session_user
name
session user name
user
name
equivalent to current_user
version()
text
PostgreSQL version information
user
current
schema
current
search path
current
The session_user is the user that initiated a
database connection; it is fixed for the duration of that
connection. The current_user is the user identifier
that is applicable for permission checking. Normally, it is equal
to the session user, but it changes during the execution of
functions with the attribute SECURITY DEFINER.
In Unix parlance, the session user is the real user
and
the current user is the effective user
.
current_user, session_user, and
user have special syntactic status in SQL:
they must be called without trailing parentheses.
current_schema returns the name of the schema that is
at the front of the search path (or a null value if the search path is
empty). This is the schema that will be used for any tables or
other named objects that are created without specifying a target schema.
current_schemas(boolean) returns an array of the names of all
schemas presently in the search path. The Boolean option determines whether or not
implicitly included system schemas such as pg_catalog> are included in the search
path returned.
The search path may be altered at run time. The command is:
SET search_path TO schema> , schema>, ...
version
version() returns a string describing the
PostgreSQL server's version.
shows the functions
available to query and alter run-time configuration parameters.
Configuration Settings Functions
Name Return Type Description
current_setting(setting_name)
text
current value of setting
set_config(setting_name,
new_value,
is_local)
text
set parameter and return new value
SET
SHOW
configuration
server
The function current_setting yields the
current value of the setting setting_name.
It corresponds to the SQL command
SHOW. An example:
SELECT current_setting('datestyle');
current_setting
-----------------
ISO, MDY
(1 row)
set_config sets the parameter
setting_name to
new_value. If
is_local is true, the
new value will only apply to the current transaction. If you want
the new value to apply for the current session, use
false instead. The function corresponds to the
SQL command SET. An example:
SELECT set_config('show_statement_stats', 'off', false);
set_config
------------
off
(1 row)
lists functions that
allow the user to query object access privileges programmatically.
See for more information about
privileges.
Access Privilege Inquiry Functions
Name Return Type Description
has_table_privilege(user,
table,
privilege)
boolean
does user have privilege for table
has_table_privilege(table,
privilege)
boolean
does current user have privilege for table
has_database_privilege(user,
database,
privilege)
boolean
does user have privilege for database
has_database_privilege(database,
privilege)
boolean
does current user have privilege for database
has_function_privilege(user,
function,
privilege)
boolean
does user have privilege for function
has_function_privilege(function,
privilege)
boolean
does current user have privilege for function
has_language_privilege(user,
language,
privilege)
boolean
does user have privilege for language
has_language_privilege(language,
privilege)
boolean
does current user have privilege for language
has_schema_privilege(user,
schema,
privilege)
boolean
does user have privilege for schema
has_schema_privilege(schema,
privilege)
boolean
does current user have privilege for schema
has_table_privilege
has_database_privilege
has_function_privilege
has_language_privilege
has_schema_privilege
has_table_privilege checks whether a user
can access a table in a particular way. The user can be
specified by name or by ID
(pg_user.usesysid), or if the argument is
omitted
current_user is assumed. The table can be specified
by name or by OID. (Thus, there are actually six variants of
has_table_privilege, which can be distinguished by
the number and types of their arguments.) When specifying by name,
the name can be schema-qualified if necessary.
The desired access privilege type
is specified by a text string, which must evaluate to one of the
values SELECT, INSERT, UPDATE,
DELETE, RULE, REFERENCES, or
TRIGGER. (Case of the string is not significant, however.)
An example is:
SELECT has_table_privilege('myschema.mytable', 'select');
has_database_privilege checks whether a user
can access a database in a particular way. The possibilities for its
arguments are analogous to has_table_privilege.
The desired access privilege type must evaluate to
CREATE,
TEMPORARY, or
TEMP (which is equivalent to
TEMPORARY).
has_function_privilege checks whether a user
can access a function in a particular way. The possibilities for its
arguments are analogous to has_table_privilege.
When specifying a function by a text string rather than by OID,
the allowed input is the same as for the regprocedure> data type.
The desired access privilege type must currently evaluate to
EXECUTE.
has_language_privilege checks whether a user
can access a procedural language in a particular way. The possibilities
for its arguments are analogous to has_table_privilege.
The desired access privilege type must currently evaluate to
USAGE.
has_schema_privilege checks whether a user
can access a schema in a particular way. The possibilities for its
arguments are analogous to has_table_privilege.
The desired access privilege type must evaluate to
CREATE or
USAGE.
To evaluate whether a user holds a grant option on the privilege,
append WITH GRANT OPTION to the privilege key
word; for example 'UPDATE WITH GRANT OPTION'.
shows functions that
determine whether a certain object is visible> in the
current schema search path. A table is said to be visible if its
containing schema is in the search path and no table of the same
name appears earlier in the search path. This is equivalent to the
statement that the table can be referenced by name without explicit
schema qualification. For example, to list the names of all
visible tables:
SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);
Schema Visibility Inquiry Functions
Name Return Type Description
pg_table_is_visible(table_oid)
boolean
is table visible in search path
pg_type_is_visible(type_oid)
boolean
is type visible in search path
pg_function_is_visible(function_oid)
boolean
is function visible in search path
pg_operator_is_visible(operator_oid)
boolean
is operator visible in search path
pg_opclass_is_visible(opclass_oid)
boolean
is operator class visible in search path
pg_conversion_is_visible(conversion_oid)
boolean
is conversion visible in search path
pg_table_is_visible
pg_type_is_visible
pg_function_is_visible
pg_operator_is_visible
pg_opclass_is_visible
pg_conversion_is_visible
pg_table_is_visible performs the check for
tables (or views, or any other kind of pg_class> entry).
pg_type_is_visible,
pg_function_is_visible,
pg_operator_is_visible,
pg_opclass_is_visible, and
pg_conversion_is_visible perform the same sort of
visibility check for types, functions, operators, operator classes
and conversions, respectively. For functions and operators, an object in
the search path is visible if there is no object of the same name
and argument data type(s)> earlier in the path. For
operator classes, both name and associated index access method are
considered.
All these functions require object OIDs to identify the object to be
checked. If you want to test an object by name, it is convenient to use
the OID alias types (regclass>, regtype>,
regprocedure>, or regoperator>), for example
SELECT pg_type_is_visible('myschema.widget'::regtype);
Note that it would not make much sense to test an unqualified name in
this way --- if the name can be recognized at all, it must be visible.
pg_get_viewdef
pg_get_ruledef
pg_get_indexdef
pg_get_triggerdef
pg_get_constraintdef
pg_get_expr
pg_get_userbyid
lists functions that
extract information from the system catalogs.
pg_get_viewdef,
pg_get_ruledef,
pg_get_indexdef,
pg_get_triggerdef, and
pg_get_constraintdef respectively
reconstruct the creating command for a view, rule, index, or
constraint. (Note that this is a decompiled reconstruction, not
the original text of the command.) Most of these come in two
variants, one of which can optionally pretty-print> the result.
The pretty-printed form is more readable but is less likely to be
interpreted the same way by future versions of PostgreSQL>;
avoid using pretty-printed output for dump purposes.
Passing false> for the pretty-print parameter yields the
same result as the variant that does not have the parameter at all.
pg_get_expr decompiles the internal form of an
individual expression, such as the default value for a column. It
may be useful when examining the contents of system catalogs.
pg_get_userbyid
extracts a user's name given a user ID number.
System Catalog Information Functions
Name Return Type Description
pg_get_viewdef(view_name)
text
get CREATE VIEW> command for view (deprecated)
pg_get_viewdef(view_name, pretty_bool>)
text
get CREATE VIEW> command for view (deprecated)
pg_get_viewdef(view_oid)
text
get CREATE VIEW> command for view
pg_get_viewdef(view_oid, pretty_bool>)
text
get CREATE VIEW> command for view
pg_get_ruledef(rule_oid)
text
get CREATE RULE> command for rule
pg_get_ruledef(rule_oid, pretty_bool>)
text
get CREATE RULE> command for rule
pg_get_indexdef(index_oid)
text
get CREATE INDEX> command for index
pg_get_indexdef(index_oid, column_no>, pretty_bool>)
text
get CREATE INDEX> command for index,
or definition of just one index column when
column_no> is not zero
pg_get_triggerdef(trigger_oid)
text
get CREATE [ CONSTRAINT ] TRIGGER> command for trigger
pg_get_constraintdef(constraint_oid)
text
get definition of a constraint
pg_get_constraintdef(constraint_oid, pretty_bool>)
text
get definition of a constraint
pg_get_expr(expr_text, relation_oid>)
text
decompile internal form of an expression, assuming that any Vars
in it refer to the relation indicated by the second parameter
pg_get_expr(expr_text, relation_oid>, pretty_bool>)
text
decompile internal form of an expression, assuming that any Vars
in it refer to the relation indicated by the second parameter
pg_get_userbyid(userid)
name
get user name with given ID
obj_description
col_description
The function shown in extract comments
previously stored with the COMMENT command. A
null value is returned if no comment could be found matching the
specified parameters.
The two-parameter form of obj_description returns the
comment for a database object specified by its OID and the name of the
containing system catalog. For example,
obj_description(123456,'pg_class')
would retrieve the comment for a table with OID 123456.
The one-parameter form of obj_description requires only
the object OID. It is now deprecated since there is no guarantee that
OIDs are unique across different system catalogs; therefore, the wrong
comment could be returned.
col_description returns the comment for a table column,
which is specified by the OID of its table and its column number.
obj_description cannot be used for table columns since
columns do not have OIDs of their own.
Array Functions
shows the operators
available for the array types.
array Operators
Operator
Description
Example
Result
=
equals
ARRAY[1.1,2.1,3.1]::int[] = ARRAY[1,2,3]
t
||
array-to-array concatenation
ARRAY[1,2,3] || ARRAY[4,5,6]
{{1,2,3},{4,5,6}}
||
array-to-array concatenation
ARRAY[1,2,3] || ARRAY[[4,5,6],[7,8,9]]
{{1,2,3},{4,5,6},{7,8,9}}
||
element-to-array concatenation
3 || ARRAY[4,5,6]
{3,4,5,6}
||
array-to-element concatenation
ARRAY[4,5,6] || 7
{4,5,6,7}
shows the functions
available for use with array types. See
for more discussion and examples for the use of these functions.
array Functions
Function
Return Type
Description
Example
Result
array_append
(anyarray, anyelement)
anyarray
append an element to the end of an array, returning
NULL for NULL inputs
array_append(ARRAY[1,2], 3)
{1,2,3}
array_cat
(anyarray, anyarray)
anyarray
concatenate two arrays, returning NULL
for NULL inputs
array_cat(ARRAY[1,2,3], ARRAY[4,5,6])
{{1,2,3},{4,5,6}}
array_dims
(anyarray)
text
returns a text representation of array dimension lower and upper bounds,
generating an ERROR for NULL inputs
array_dims(array[[1,2,3],[4,5,6]])
[1:2][1:3]
array_lower
(anyarray, integer)
integer
returns lower bound of the requested array dimension, returning
NULL for NULL inputs
array_lower(array_prepend(0, ARRAY[1,2,3]), 1)
0
array_prepend
(anyelement, anyarray)
anyarray
append an element to the beginning of an array, returning
NULL for NULL inputs
array_prepend(1, ARRAY[2,3])
{1,2,3}
array_to_string
(anyarray, text)
text
concatenates array elements using provided delimiter, returning
NULL for NULL inputs
array_to_string(array[1.1,2.2,3.3]::numeric(4,2)[],'~^~')
1.10~^~2.20~^~3.30
array_upper
(anyarray, integer)
integer
returns upper bound of the requested array dimension, returning
NULL for NULL inputs
array_upper(array_append(ARRAY[1,2,3], 4), 1)
4
string_to_array
(text, text)
text[]
splits string into array elements using provided delimiter, returning
NULL for NULL inputs
string_to_array('1.10~^~2.20~^~3.30','~^~')::float8[]
{1.1,2.2,3.3}
Aggregate Functions
Aggregate functions compute a single result
value from a set of input values. shows the built-in aggregate
functions. The special syntax considerations for aggregate
functions are explained in .
Consult for additional introductory
information.
Aggregate Functions
Function
Argument Type
Return Type
Description
average
function
avg(expression)
smallint, integer,
bigint, real, double
precision, numeric, or interval
numeric for any integer type argument,
double precision for a floating-point argument,
otherwise the same as the argument data type
the average (arithmetic mean) of all input values
count(*)
bigint
number of input values
count(expression)
any
bigint
number of input values for which the value of expression is not null
max(expression)
any numeric, string, or date/time type
same as argument type
maximum value of expression across all input
values
min(expression)
any numeric, string, or date/time type
same as argument type
minimum value of expression across all input
values
standard deviation
stddev(expression)
smallint, integer,
bigint, real, double
precision, or numeric
double precision for floating-point arguments,
otherwise numeric
sample standard deviation of the input values
sum(expression)
smallint, integer,
bigint, real, double
precision, numeric, or
interval
bigint for smallint or
integer arguments, numeric for
bigint arguments, double precision
for floating-point arguments, otherwise the same as the
argument data type
sum of expression across all input values
variance
variance(expression)
smallint, integer,
bigint, real, double
precision, or numeric
double precision for floating-point arguments,
otherwise numeric
sample variance of the input values (square of the sample standard deviation)
It should be noted that except for count,
these functions return a null value when no rows are selected. In
particular, sum of no rows returns null, not
zero as one might expect. The function coalesce may be
used to substitute zero for null when necessary.
Users accustomed to working with other RDBMS products may be
surprised by the performance characteristics of certain aggregate
functions in PostgreSQL when the
aggregate is applied to the entire table (in other words, no
WHERE clause is specified). In particular,
a query like
SELECT min(col) FROM sometable;
will be executed by PostgreSQL using a
sequential scan of the entire table. Other database systems may
optimize queries of this form to use an index on the column, if one
is available. Similarly, the aggregate functions
max() and count() always
require a sequential scan if applied to the entire table in
PostgreSQL.
PostgreSQL cannot easily implement this
optimization because it also allows for user-defined aggregate
queries. Since min(),
max(), and count() are
defined using a generic API for aggregate functions, there is no
provision for special-casing
the execution of these
functions under certain circumstances.
Fortunately, there is a simple workaround for
min() and max(). The
query shown below is equivalent to the query above, except that it
can take advantage of a B+-Tree index if there is one present on
the column in question.
SELECT col FROM sometable ORDER BY col ASC LIMIT 1;
A similar query (obtained by substituting DESC
for ASC in the query above) can be used in the
place of max()).
Unfortunately, there is no similarly trivial query that can be
used to improve the performance of count()
when applied to the entire table.
Subquery Expressions
exists
in
not in
any
all
some
subqueries
This section describes the SQL-compliant subquery
expressions available in PostgreSQL.
All of the expression forms documented in this section return
Boolean (true/false) results.
EXISTS
EXISTS ( subquery )
The argument of EXISTS is an arbitrary SELECT> statement,
or subquery. The
subquery is evaluated to determine whether it returns any rows.
If it returns at least one row, the result of EXISTS is
true>; if the subquery returns no rows, the result of EXISTS
is false>.
The subquery can refer to variables from the surrounding query,
which will act as constants during any one evaluation of the subquery.
The subquery will generally only be executed far enough to determine
whether at least one row is returned, not all the way to completion.
It is unwise to write a subquery that has any side effects (such as
calling sequence functions); whether the side effects occur or not
may be difficult to predict.
Since the result depends only on whether any rows are returned,
and not on the contents of those rows, the output list of the
subquery is normally uninteresting. A common coding convention is
to write all EXISTS> tests in the form
EXISTS(SELECT 1 WHERE ...). There are exceptions to
this rule however, such as subqueries that use INTERSECT.
This simple example is like an inner join on col2>, but
it produces at most one output row for each tab1> row,
even if there are multiple matching tab2> rows:
SELECT col1 FROM tab1
WHERE EXISTS(SELECT 1 FROM tab2 WHERE col2 = tab1.col2);
IN
expression IN (subquery)
The right-hand side is a parenthesized
subquery, which must return exactly one column. The left-hand expression
is evaluated and compared to each row of the subquery result.
The result of IN is true> if any equal subquery row is found.
The result is false> if no equal row is found (including the special
case where the subquery returns no rows).
Note that if the left-hand expression yields null, or if there are
no equal right-hand values and at least one right-hand row yields
null, the result of the IN construct will be null, not false.
This is in accordance with SQL's normal rules for Boolean combinations
of null values.
As with EXISTS, it's unwise to assume that the subquery will
be evaluated completely.
(expression , expression ...) IN (subquery)
The right-hand side of this form of IN is a parenthesized
subquery, which must return exactly as many columns as there are
expressions in the left-hand list. The left-hand expressions are
evaluated and compared row-wise to each row of the subquery result.
The result of IN is true> if any equal subquery row is found.
The result is false> if no equal row is found (including the special
case where the subquery returns no rows).
As usual, null values in the rows are combined per
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (null).
If all the row results are either unequal or null, with at least one null,
then the result of IN is null.
NOT IN
expression NOT IN (subquery)
The right-hand side is a parenthesized
subquery, which must return exactly one column. The left-hand expression
is evaluated and compared to each row of the subquery result.
The result of NOT IN is true> if only unequal subquery rows
are found (including the special case where the subquery returns no rows).
The result is false> if any equal row is found.
Note that if the left-hand expression yields null, or if there are
no equal right-hand values and at least one right-hand row yields
null, the result of the NOT IN construct will be null, not true.
This is in accordance with SQL's normal rules for Boolean combinations
of null values.
As with EXISTS, it's unwise to assume that the subquery will
be evaluated completely.
(expression , expression ...) NOT IN (subquery)
The right-hand side of this form of NOT IN is a parenthesized
subquery, which must return exactly as many columns as there are
expressions in the left-hand list. The left-hand expressions are
evaluated and compared row-wise to each row of the subquery result.
The result of NOT IN is true> if only unequal subquery rows
are found (including the special case where the subquery returns no rows).
The result is false> if any equal row is found.
As usual, null values in the rows are combined per
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (null).
If all the row results are either unequal or null, with at least one null,
then the result of NOT IN is null.
ANY/SOME
expression operator ANY (subquery)
expression operator SOME (subquery)
The right-hand side is a parenthesized
subquery, which must return exactly one column. The left-hand expression
is evaluated and compared to each row of the subquery result using the
given operator, which must yield a Boolean
result.
The result of ANY is true> if any true result is obtained.
The result is false> if no true result is found (including the special
case where the subquery returns no rows).
SOME is a synonym for ANY.
IN is equivalent to = ANY.
Note that if there are no successes and at least one right-hand row yields
null for the operator's result, the result of the ANY construct
will be null, not false.
This is in accordance with SQL's normal rules for Boolean combinations
of null values.
As with EXISTS, it's unwise to assume that the subquery will
be evaluated completely.
(expression , expression ...) operator> ANY (subquery)
(expression , expression ...) operator> SOME (subquery)
The right-hand side of this form of ANY is a parenthesized
subquery, which must return exactly as many columns as there are
expressions in the left-hand list. The left-hand expressions are
evaluated and compared row-wise to each row of the subquery result,
using the given operator. Presently,
only = and <> operators are allowed
in row-wise ANY constructs.
The result of ANY is true> if any equal or unequal row is
found, respectively.
The result is false> if no such row is found (including the special
case where the subquery returns no rows).
As usual, null values in the rows are combined per
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (null).
If there is at least one null row result, then the result of ANY
cannot be false; it will be true or null.
ALL
expression operator ALL (subquery)
The right-hand side is a parenthesized
subquery, which must return exactly one column. The left-hand expression
is evaluated and compared to each row of the subquery result using the
given operator, which must yield a Boolean
result.
The result of ALL is true> if all rows yield true
(including the special case where the subquery returns no rows).
The result is false> if any false result is found.
NOT IN is equivalent to <> ALL.
Note that if there are no failures but at least one right-hand row yields
null for the operator's result, the result of the ALL construct
will be null, not true.
This is in accordance with SQL's normal rules for Boolean combinations
of null values.
As with EXISTS, it's unwise to assume that the subquery will
be evaluated completely.
(expression , expression ...) operator ALL (subquery)
The right-hand side of this form of ALL is a parenthesized
subquery, which must return exactly as many columns as there are
expressions in the left-hand list. The left-hand expressions are
evaluated and compared row-wise to each row of the subquery result,
using the given operator. Presently,
only = and <> operators are allowed
in row-wise ALL queries.
The result of ALL is true> if all subquery rows are equal
or unequal, respectively (including the special
case where the subquery returns no rows).
The result is false> if any row is found to be unequal or equal,
respectively.
As usual, null values in the rows are combined per
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (null).
If there is at least one null row result, then the result of ALL
cannot be true; it will be false or null.
Row-wise Comparison
(expression , expression ...) operator (subquery)
The left-hand side is a list of scalar expressions. The right-hand side is
a parenthesized subquery, which must return exactly as many columns as there
are expressions on the left-hand side. Furthermore, the subquery cannot
return more than one row. (If it returns zero rows, the result is taken to
be null.) The left-hand side is evaluated and compared row-wise to the
single subquery result row.
Presently, only = and <> operators are allowed
in row-wise comparisons.
The result is true> if the two rows are equal or unequal, respectively.
As usual, null values in the rows are combined per
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of the row comparison is unknown (null).
Row and Array Comparisons
in
not in
any
all
some
This section describes several specialized constructs for making
multiple comparisons between groups of values. These forms are
syntactically related to the subquery forms of the previous section,
but do not involve subqueries.
The forms involving array subexpressions are
PostgreSQL extensions; the rest are
SQL-compliant.
All of the expression forms documented in this section return
Boolean (true/false) results.
IN
expression IN (value, ...)
The right-hand side is a parenthesized list
of scalar expressions. The result is true> if the left-hand expression's
result is equal to any of the right-hand expressions. This is a shorthand
notation for
expression = value1
OR
expression = value2
OR
...
Note that if the left-hand expression yields null, or if there are
no equal right-hand values and at least one right-hand expression yields
null, the result of the IN construct will be null, not false.
This is in accordance with SQL's normal rules for Boolean combinations
of null values.
NOT IN
expression NOT IN (value, ...)
The right-hand side is a parenthesized list
of scalar expressions. The result is true
if the left-hand expression's
result is unequal to all of the right-hand expressions. This is a shorthand
notation for
expression <> value1
AND
expression <> value2
AND
...
Note that if the left-hand expression yields null, or if there are
no equal right-hand values and at least one right-hand expression yields
null, the result of the NOT IN construct will be null, not true
as one might naively expect.
This is in accordance with SQL's normal rules for Boolean combinations
of null values.
x NOT IN y is equivalent to NOT (x IN y) in all
cases. However, null values are much more likely to trip up the novice when
working with NOT IN than when working with IN.
It's best to express your condition positively if possible.
ANY/SOME (array)
expression operator ANY (array expression)
expression operator SOME (array expression)
The right-hand side is a parenthesized expression, which must yield an
array value.
The left-hand expression
is evaluated and compared to each element of the array using the
given operator, which must yield a Boolean
result.
The result of ANY is true> if any true result is obtained.
The result is false> if no true result is found (including the special
case where the array has zero elements).
SOME is a synonym for ANY.
ALL (array)
expression operator ALL (array expression)
The right-hand side is a parenthesized expression, which must yield an
array value.
The left-hand expression
is evaluated and compared to each element of the array using the
given operator, which must yield a Boolean
result.
The result of ALL is true> if all comparisons yield true
(including the special case where the array has zero elements).
The result is false> if any false result is found.
Row-wise Comparison
(expression , expression ...) operator (expression , expression ...)
Each side is a list of scalar expressions; the two lists must be
of the same length. Each side is evaluated and they are compared
row-wise.
Presently, only = and <> operators are allowed
in row-wise comparisons.
The result is true> if the two rows are equal or unequal, respectively.
As usual, null values in the rows are combined per
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of the row comparison is unknown (null).