2000-01-05 07:06:23 +01:00
|
|
|
--
|
|
|
|
-- STRINGS
|
|
|
|
-- Test various data entry syntaxes.
|
|
|
|
--
|
|
|
|
-- SQL92 string continuation syntax
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E021-03 character string literals
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT 'first line'
|
1997-12-01 03:48:47 +01:00
|
|
|
' - next line'
|
|
|
|
' - third line'
|
|
|
|
AS "Three lines to one";
|
2000-01-05 07:06:23 +01:00
|
|
|
Three lines to one
|
|
|
|
-------------------------------------
|
|
|
|
first line - next line - third line
|
1997-12-01 03:48:47 +01:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
-- illegal string continuation syntax
|
|
|
|
SELECT 'first line'
|
1997-12-01 03:48:47 +01:00
|
|
|
' - next line' /* this comment is not allowed here */
|
1998-05-29 15:22:42 +02:00
|
|
|
' - third line'
|
|
|
|
AS "Illegal comment within continuation";
|
2003-05-29 22:40:36 +02:00
|
|
|
ERROR: syntax error at or near "' - third line'" at character 75
|
2004-03-14 05:25:18 +01:00
|
|
|
LINE 3: ' - third line'
|
|
|
|
^
|
2000-01-05 07:06:23 +01:00
|
|
|
--
|
|
|
|
-- test conversions between various string types
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E021-10 implicit casting among the character data types
|
2000-01-05 07:06:23 +01:00
|
|
|
--
|
|
|
|
SELECT CAST(f1 AS text) AS "text(char)" FROM CHAR_TBL;
|
|
|
|
text(char)
|
|
|
|
------------
|
2003-05-26 02:11:29 +02:00
|
|
|
a
|
|
|
|
ab
|
2000-01-05 07:06:23 +01:00
|
|
|
abcd
|
|
|
|
abcd
|
1998-05-29 15:22:42 +02:00
|
|
|
(4 rows)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT CAST(f1 AS text) AS "text(varchar)" FROM VARCHAR_TBL;
|
|
|
|
text(varchar)
|
|
|
|
---------------
|
|
|
|
a
|
|
|
|
ab
|
|
|
|
abcd
|
|
|
|
abcd
|
1998-05-29 15:22:42 +02:00
|
|
|
(4 rows)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT CAST(name 'namefield' AS text) AS "text(name)";
|
|
|
|
text(name)
|
|
|
|
------------
|
|
|
|
namefield
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
-- since this is an explicit cast, it should truncate w/o error:
|
|
|
|
SELECT CAST(f1 AS char(10)) AS "char(text)" FROM TEXT_TBL;
|
|
|
|
char(text)
|
|
|
|
------------
|
|
|
|
doh!
|
|
|
|
hi de ho n
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- note: implicit-cast case is tested in char.sql
|
2001-05-21 18:54:46 +02:00
|
|
|
SELECT CAST(f1 AS char(20)) AS "char(text)" FROM TEXT_TBL;
|
|
|
|
char(text)
|
|
|
|
----------------------
|
|
|
|
doh!
|
|
|
|
hi de ho neighbor
|
1998-05-29 15:22:42 +02:00
|
|
|
(2 rows)
|
|
|
|
|
2000-01-17 01:16:41 +01:00
|
|
|
SELECT CAST(f1 AS char(10)) AS "char(varchar)" FROM VARCHAR_TBL;
|
2000-01-05 07:06:23 +01:00
|
|
|
char(varchar)
|
|
|
|
---------------
|
2000-01-17 01:16:41 +01:00
|
|
|
a
|
|
|
|
ab
|
|
|
|
abcd
|
|
|
|
abcd
|
1998-05-29 15:22:42 +02:00
|
|
|
(4 rows)
|
|
|
|
|
2000-01-17 01:16:41 +01:00
|
|
|
SELECT CAST(name 'namefield' AS char(10)) AS "char(name)";
|
2000-01-05 07:06:23 +01:00
|
|
|
char(name)
|
|
|
|
------------
|
2000-01-17 01:16:41 +01:00
|
|
|
namefield
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT CAST(f1 AS varchar) AS "varchar(text)" FROM TEXT_TBL;
|
|
|
|
varchar(text)
|
|
|
|
-------------------
|
|
|
|
doh!
|
|
|
|
hi de ho neighbor
|
1998-05-29 15:22:42 +02:00
|
|
|
(2 rows)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT CAST(f1 AS varchar) AS "varchar(char)" FROM CHAR_TBL;
|
|
|
|
varchar(char)
|
|
|
|
---------------
|
2003-05-26 02:11:29 +02:00
|
|
|
a
|
|
|
|
ab
|
2000-01-05 07:06:23 +01:00
|
|
|
abcd
|
|
|
|
abcd
|
1998-05-29 15:22:42 +02:00
|
|
|
(4 rows)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT CAST(name 'namefield' AS varchar) AS "varchar(name)";
|
|
|
|
varchar(name)
|
|
|
|
---------------
|
|
|
|
namefield
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
--
|
|
|
|
-- test SQL92 string functions
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E### and T### are feature reference numbers from SQL99
|
2000-01-05 07:06:23 +01:00
|
|
|
--
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E021-09 trim function
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT TRIM(BOTH FROM ' bunch o blanks ') = 'bunch o blanks' AS "bunch o blanks";
|
2000-01-05 07:06:23 +01:00
|
|
|
bunch o blanks
|
|
|
|
----------------
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT TRIM(LEADING FROM ' bunch o blanks ') = 'bunch o blanks ' AS "bunch o blanks ";
|
2000-01-05 07:06:23 +01:00
|
|
|
bunch o blanks
|
|
|
|
------------------
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT TRIM(TRAILING FROM ' bunch o blanks ') = ' bunch o blanks' AS " bunch o blanks";
|
2000-01-05 07:06:23 +01:00
|
|
|
bunch o blanks
|
|
|
|
------------------
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT TRIM(BOTH 'x' FROM 'xxxxxsome Xsxxxxx') = 'some Xs' AS "some Xs";
|
2000-01-05 07:06:23 +01:00
|
|
|
some Xs
|
|
|
|
---------
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E021-06 substring expression
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT SUBSTRING('1234567890' FROM 3) = '34567890' AS "34567890";
|
2000-01-05 07:06:23 +01:00
|
|
|
34567890
|
|
|
|
----------
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT SUBSTRING('1234567890' FROM 4 FOR 3) = '456' AS "456";
|
2000-01-05 07:06:23 +01:00
|
|
|
456
|
|
|
|
-----
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2002-09-22 19:27:25 +02:00
|
|
|
-- T581 regular expression substring (with SQL99's bizarre regexp syntax)
|
|
|
|
SELECT SUBSTRING('abcdefg' FROM 'a#"(b_d)#"%' FOR '#') AS "bcd";
|
2002-06-11 17:44:38 +02:00
|
|
|
bcd
|
|
|
|
-----
|
|
|
|
bcd
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- No match should return NULL
|
2002-09-22 19:27:25 +02:00
|
|
|
SELECT SUBSTRING('abcdefg' FROM '#"(b_d)#"%' FOR '#') IS NULL AS "True";
|
2002-06-11 17:44:38 +02:00
|
|
|
True
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Null inputs should return NULL
|
|
|
|
SELECT SUBSTRING('abcdefg' FROM '(b|c)' FOR NULL) IS NULL AS "True";
|
|
|
|
True
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT SUBSTRING(NULL FROM '(b|c)' FOR '#') IS NULL AS "True";
|
|
|
|
True
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT SUBSTRING('abcdefg' FROM NULL FOR '#') IS NULL AS "True";
|
|
|
|
True
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2002-09-22 19:27:25 +02:00
|
|
|
-- PostgreSQL extension to allow omitting the escape character;
|
|
|
|
-- here the regexp is taken as Posix syntax
|
|
|
|
SELECT SUBSTRING('abcdefg' FROM 'c.e') AS "cde";
|
|
|
|
cde
|
|
|
|
-----
|
|
|
|
cde
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- With a parenthesized subexpression, return only what matches the subexpr
|
|
|
|
SELECT SUBSTRING('abcdefg' FROM 'b(.*)f') AS "cde";
|
2002-06-11 17:44:38 +02:00
|
|
|
cde
|
|
|
|
-----
|
|
|
|
cde
|
|
|
|
(1 row)
|
|
|
|
|
2005-07-10 06:54:33 +02:00
|
|
|
-- PostgreSQL extension to allow using back reference in replace string;
|
|
|
|
SELECT regexp_replace('1112223333', '(\\d{3})(\\d{3})(\\d{4})', '(\\1) \\2-\\3');
|
|
|
|
regexp_replace
|
|
|
|
----------------
|
|
|
|
(111) 222-3333
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT regexp_replace('AAA BBB CCC ', '\\s+', ' ', 'g');
|
|
|
|
regexp_replace
|
|
|
|
----------------
|
|
|
|
AAA BBB CCC
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT regexp_replace('AAA', '^|$', 'Z', 'g');
|
|
|
|
regexp_replace
|
|
|
|
----------------
|
|
|
|
ZAAAZ
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT regexp_replace('AAA aaa', 'A+', 'Z', 'gi');
|
|
|
|
regexp_replace
|
|
|
|
----------------
|
|
|
|
Z Z
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- invalid option of REGEXP_REPLACE
|
|
|
|
SELECT regexp_replace('AAA aaa', 'A+', 'Z', 'z');
|
|
|
|
ERROR: invalid option of regexp_replace: z
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E021-11 position expression
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT POSITION('4' IN '1234567890') = '4' AS "4";
|
2000-01-05 07:06:23 +01:00
|
|
|
4
|
|
|
|
---
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT POSITION(5 IN '1234567890') = '5' AS "5";
|
2000-01-05 07:06:23 +01:00
|
|
|
5
|
|
|
|
---
|
2000-08-07 03:43:14 +02:00
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2002-06-11 17:44:38 +02:00
|
|
|
-- T312 character overlay function
|
|
|
|
SELECT OVERLAY('abcdef' PLACING '45' FROM 4) AS "abc45f";
|
|
|
|
abc45f
|
|
|
|
--------
|
|
|
|
abc45f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT OVERLAY('yabadoo' PLACING 'daba' FROM 5) AS "yabadaba";
|
|
|
|
yabadaba
|
|
|
|
----------
|
|
|
|
yabadaba
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT OVERLAY('yabadoo' PLACING 'daba' FROM 5 FOR 0) AS "yabadabadoo";
|
|
|
|
yabadabadoo
|
|
|
|
-------------
|
|
|
|
yabadabadoo
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT OVERLAY('babosa' PLACING 'ubb' FROM 2 FOR 4) AS "bubba";
|
|
|
|
bubba
|
|
|
|
-------
|
|
|
|
bubba
|
|
|
|
(1 row)
|
|
|
|
|
2000-08-07 03:43:14 +02:00
|
|
|
--
|
|
|
|
-- test LIKE
|
|
|
|
-- Be sure to form every test as a LIKE/NOT LIKE pair.
|
|
|
|
--
|
|
|
|
-- simplest examples
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E061-04 like predicate
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT 'hawkeye' LIKE 'h%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT LIKE 'h%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' LIKE 'H%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT LIKE 'H%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' LIKE 'indio%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT LIKE 'indio%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' LIKE 'h%eye' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT LIKE 'h%eye' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' LIKE '_ndio' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' NOT LIKE '_ndio' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' LIKE 'in__o' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' NOT LIKE 'in__o' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' LIKE 'in_o' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' NOT LIKE 'in_o' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- unused escape character
|
|
|
|
SELECT 'hawkeye' LIKE 'h%' ESCAPE '#' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT LIKE 'h%' ESCAPE '#' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' LIKE 'ind_o' ESCAPE '$' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' NOT LIKE 'ind_o' ESCAPE '$' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- escape character
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E061-05 like predicate with escape clause
|
2000-08-07 03:43:14 +02:00
|
|
|
SELECT 'h%' LIKE 'h#%' ESCAPE '#' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'h%' NOT LIKE 'h#%' ESCAPE '#' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'h%wkeye' LIKE 'h#%' ESCAPE '#' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'h%wkeye' NOT LIKE 'h#%' ESCAPE '#' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'h%wkeye' LIKE 'h#%%' ESCAPE '#' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'h%wkeye' NOT LIKE 'h#%%' ESCAPE '#' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'h%awkeye' LIKE 'h#%a%k%e' ESCAPE '#' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'h%awkeye' NOT LIKE 'h#%a%k%e' ESCAPE '#' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' LIKE '_ndio' ESCAPE '$' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'indio' NOT LIKE '_ndio' ESCAPE '$' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'i_dio' LIKE 'i$_d_o' ESCAPE '$' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'i_dio' NOT LIKE 'i$_d_o' ESCAPE '$' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'i_dio' LIKE 'i$_nd_o' ESCAPE '$' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'i_dio' NOT LIKE 'i$_nd_o' ESCAPE '$' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'i_dio' LIKE 'i$_d%o' ESCAPE '$' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'i_dio' NOT LIKE 'i$_d%o' ESCAPE '$' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- escape character same as pattern character
|
|
|
|
SELECT 'maca' LIKE 'm%aca' ESCAPE '%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'maca' NOT LIKE 'm%aca' ESCAPE '%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'ma%a' LIKE 'm%a%%a' ESCAPE '%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'ma%a' NOT LIKE 'm%a%%a' ESCAPE '%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'bear' LIKE 'b_ear' ESCAPE '_' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'bear' NOT LIKE 'b_ear' ESCAPE '_' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'be_r' LIKE 'b_e__r' ESCAPE '_' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'be_r' NOT LIKE 'b_e__r' ESCAPE '_' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'be_r' LIKE '__e__r' ESCAPE '_' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'be_r' NOT LIKE '__e__r' ESCAPE '_' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- test ILIKE (case-insensitive LIKE)
|
|
|
|
-- Be sure to form every test as an ILIKE/NOT ILIKE pair.
|
|
|
|
--
|
|
|
|
SELECT 'hawkeye' ILIKE 'h%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT ILIKE 'h%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' ILIKE 'H%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT ILIKE 'H%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' ILIKE 'H%Eye' AS "true";
|
|
|
|
true
|
|
|
|
------
|
2000-09-15 20:45:31 +02:00
|
|
|
t
|
2000-08-07 03:43:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'hawkeye' NOT ILIKE 'H%Eye' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
2000-09-15 20:45:31 +02:00
|
|
|
f
|
2000-08-07 03:43:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'Hawkeye' ILIKE 'h%' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'Hawkeye' NOT ILIKE 'h%' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
--
|
|
|
|
-- test implicit type conversion
|
|
|
|
--
|
2002-06-11 17:44:38 +02:00
|
|
|
-- E021-07 character concatenation
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT 'unknown' || ' and unknown' AS "Concat unknown types";
|
|
|
|
Concat unknown types
|
|
|
|
----------------------
|
|
|
|
unknown and unknown
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT text 'text' || ' and unknown' AS "Concat text to unknown type";
|
|
|
|
Concat text to unknown type
|
|
|
|
-----------------------------
|
|
|
|
text and unknown
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2003-05-26 02:11:29 +02:00
|
|
|
SELECT char(20) 'characters' || ' and text' AS "Concat char to unknown type";
|
|
|
|
Concat char to unknown type
|
|
|
|
-----------------------------
|
|
|
|
characters and text
|
2001-06-01 19:49:17 +02:00
|
|
|
(1 row)
|
|
|
|
|
2001-05-21 18:54:46 +02:00
|
|
|
SELECT text 'text' || char(20) ' and characters' AS "Concat text to char";
|
2003-05-26 02:11:29 +02:00
|
|
|
Concat text to char
|
|
|
|
---------------------
|
|
|
|
text and characters
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 07:06:23 +01:00
|
|
|
SELECT text 'text' || varchar ' and varchar' AS "Concat text to varchar";
|
|
|
|
Concat text to varchar
|
|
|
|
------------------------
|
|
|
|
text and varchar
|
1998-05-29 15:22:42 +02:00
|
|
|
(1 row)
|
|
|
|
|
2002-08-22 05:24:01 +02:00
|
|
|
--
|
|
|
|
-- test substr with toasted text values
|
|
|
|
--
|
|
|
|
CREATE TABLE toasttest(f1 text);
|
|
|
|
insert into toasttest values(repeat('1234567890',10000));
|
|
|
|
insert into toasttest values(repeat('1234567890',10000));
|
2002-08-28 22:18:29 +02:00
|
|
|
--
|
|
|
|
-- Ensure that some values are uncompressed, to test the faster substring
|
|
|
|
-- operation used in that case
|
|
|
|
--
|
|
|
|
alter table toasttest alter column f1 set storage external;
|
|
|
|
insert into toasttest values(repeat('1234567890',10000));
|
|
|
|
insert into toasttest values(repeat('1234567890',10000));
|
2002-08-22 05:24:01 +02:00
|
|
|
-- If the starting position is zero or less, then return from the start of the string
|
|
|
|
-- adjusting the length to be consistent with the "negative start" per SQL92.
|
|
|
|
SELECT substr(f1, -1, 5) from toasttest;
|
|
|
|
substr
|
|
|
|
--------
|
|
|
|
123
|
|
|
|
123
|
2002-08-28 22:18:29 +02:00
|
|
|
123
|
|
|
|
123
|
|
|
|
(4 rows)
|
2002-08-22 05:24:01 +02:00
|
|
|
|
|
|
|
-- If the length is less than zero, an ERROR is thrown.
|
|
|
|
SELECT substr(f1, 5, -1) from toasttest;
|
|
|
|
ERROR: negative substring length not allowed
|
|
|
|
-- If no third argument (length) is provided, the length to the end of the
|
|
|
|
-- string is assumed.
|
|
|
|
SELECT substr(f1, 99995) from toasttest;
|
|
|
|
substr
|
|
|
|
--------
|
|
|
|
567890
|
|
|
|
567890
|
2002-08-28 22:18:29 +02:00
|
|
|
567890
|
|
|
|
567890
|
|
|
|
(4 rows)
|
2002-08-22 05:24:01 +02:00
|
|
|
|
|
|
|
-- If start plus length is > string length, the result is truncated to
|
|
|
|
-- string length
|
|
|
|
SELECT substr(f1, 99995, 10) from toasttest;
|
|
|
|
substr
|
|
|
|
--------
|
|
|
|
567890
|
|
|
|
567890
|
2002-08-28 22:18:29 +02:00
|
|
|
567890
|
|
|
|
567890
|
|
|
|
(4 rows)
|
2002-08-22 05:24:01 +02:00
|
|
|
|
|
|
|
DROP TABLE toasttest;
|
|
|
|
--
|
|
|
|
-- test substr with toasted bytea values
|
|
|
|
--
|
|
|
|
CREATE TABLE toasttest(f1 bytea);
|
|
|
|
insert into toasttest values(decode(repeat('1234567890',10000),'escape'));
|
|
|
|
insert into toasttest values(decode(repeat('1234567890',10000),'escape'));
|
2002-08-28 22:18:29 +02:00
|
|
|
--
|
|
|
|
-- Ensure that some values are uncompressed, to test the faster substring
|
|
|
|
-- operation used in that case
|
|
|
|
--
|
|
|
|
alter table toasttest alter column f1 set storage external;
|
|
|
|
insert into toasttest values(decode(repeat('1234567890',10000),'escape'));
|
|
|
|
insert into toasttest values(decode(repeat('1234567890',10000),'escape'));
|
2002-08-22 05:24:01 +02:00
|
|
|
-- If the starting position is zero or less, then return from the start of the string
|
|
|
|
-- adjusting the length to be consistent with the "negative start" per SQL92.
|
|
|
|
SELECT substr(f1, -1, 5) from toasttest;
|
|
|
|
substr
|
|
|
|
--------
|
|
|
|
123
|
|
|
|
123
|
2002-08-28 22:18:29 +02:00
|
|
|
123
|
|
|
|
123
|
|
|
|
(4 rows)
|
2002-08-22 05:24:01 +02:00
|
|
|
|
|
|
|
-- If the length is less than zero, an ERROR is thrown.
|
|
|
|
SELECT substr(f1, 5, -1) from toasttest;
|
|
|
|
ERROR: negative substring length not allowed
|
|
|
|
-- If no third argument (length) is provided, the length to the end of the
|
|
|
|
-- string is assumed.
|
|
|
|
SELECT substr(f1, 99995) from toasttest;
|
|
|
|
substr
|
|
|
|
--------
|
|
|
|
567890
|
|
|
|
567890
|
2002-08-28 22:18:29 +02:00
|
|
|
567890
|
|
|
|
567890
|
|
|
|
(4 rows)
|
2002-08-22 05:24:01 +02:00
|
|
|
|
|
|
|
-- If start plus length is > string length, the result is truncated to
|
|
|
|
-- string length
|
|
|
|
SELECT substr(f1, 99995, 10) from toasttest;
|
|
|
|
substr
|
|
|
|
--------
|
|
|
|
567890
|
|
|
|
567890
|
2002-08-28 22:18:29 +02:00
|
|
|
567890
|
|
|
|
567890
|
|
|
|
(4 rows)
|
2002-08-22 05:24:01 +02:00
|
|
|
|
|
|
|
DROP TABLE toasttest;
|
|
|
|
--
|
|
|
|
-- test length
|
|
|
|
--
|
|
|
|
SELECT length('abcdef') AS "length_6";
|
|
|
|
length_6
|
|
|
|
----------
|
|
|
|
6
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- test strpos
|
|
|
|
--
|
|
|
|
SELECT strpos('abcdef', 'cd') AS "pos_3";
|
|
|
|
pos_3
|
|
|
|
-------
|
|
|
|
3
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT strpos('abcdef', 'xy') AS "pos_0";
|
|
|
|
pos_0
|
|
|
|
-------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- test replace
|
|
|
|
--
|
|
|
|
SELECT replace('abcdef', 'de', '45') AS "abc45f";
|
|
|
|
abc45f
|
|
|
|
--------
|
|
|
|
abc45f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT replace('yabadabadoo', 'ba', '123') AS "ya123da123doo";
|
|
|
|
ya123da123doo
|
|
|
|
---------------
|
|
|
|
ya123da123doo
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT replace('yabadoo', 'bad', '') AS "yaoo";
|
|
|
|
yaoo
|
|
|
|
------
|
|
|
|
yaoo
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
Joe Conway wrote:
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Joe Conway
2002-09-12 02:21:25 +02:00
|
|
|
-- test split_part
|
2002-08-22 05:24:01 +02:00
|
|
|
--
|
Joe Conway wrote:
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Joe Conway
2002-09-12 02:21:25 +02:00
|
|
|
select split_part('joeuser@mydatabase','@',0) AS "an error";
|
2003-07-27 06:53:12 +02:00
|
|
|
ERROR: field position must be greater than zero
|
Joe Conway wrote:
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Joe Conway
2002-09-12 02:21:25 +02:00
|
|
|
select split_part('joeuser@mydatabase','@',1) AS "joeuser";
|
2002-08-22 05:24:01 +02:00
|
|
|
joeuser
|
|
|
|
---------
|
|
|
|
joeuser
|
|
|
|
(1 row)
|
|
|
|
|
Joe Conway wrote:
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Joe Conway
2002-09-12 02:21:25 +02:00
|
|
|
select split_part('joeuser@mydatabase','@',2) AS "mydatabase";
|
2002-08-22 05:24:01 +02:00
|
|
|
mydatabase
|
|
|
|
------------
|
|
|
|
mydatabase
|
|
|
|
(1 row)
|
|
|
|
|
Joe Conway wrote:
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Joe Conway
2002-09-12 02:21:25 +02:00
|
|
|
select split_part('joeuser@mydatabase','@',3) AS "empty string";
|
2002-08-22 05:24:01 +02:00
|
|
|
empty string
|
|
|
|
--------------
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
Joe Conway wrote:
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Joe Conway
2002-09-12 02:21:25 +02:00
|
|
|
select split_part('@joeuser@mydatabase@','@',2) AS "joeuser";
|
2002-08-22 05:24:01 +02:00
|
|
|
joeuser
|
|
|
|
---------
|
|
|
|
joeuser
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- test to_hex
|
|
|
|
--
|
|
|
|
select to_hex(256*256*256 - 1) AS "ffffff";
|
|
|
|
ffffff
|
|
|
|
--------
|
|
|
|
ffffff
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_hex(256::bigint*256::bigint*256::bigint*256::bigint - 1) AS "ffffffff";
|
|
|
|
ffffffff
|
|
|
|
----------
|
|
|
|
ffffffff
|
|
|
|
(1 row)
|
|
|
|
|
2002-12-06 06:20:28 +01:00
|
|
|
--
|
|
|
|
-- MD5 test suite - from IETF RFC 1321
|
|
|
|
-- (see: ftp://ftp.rfc-editor.org/in-notes/rfc1321.txt)
|
|
|
|
--
|
|
|
|
select md5('') = 'd41d8cd98f00b204e9800998ecf8427e' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('a') = '0cc175b9c0f1b6a831c399e269772661' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('abc') = '900150983cd24fb0d6963f7d28e17f72' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('message digest') = 'f96b697d7cb7938d525a2f31aaf161d0' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('abcdefghijklmnopqrstuvwxyz') = 'c3fcd3d76192e4007dfb496cca67e13b' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789') = 'd174ab98d277d9f5a5611c2c9f419d9f' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('12345678901234567890123456789012345678901234567890123456789012345678901234567890') = '57edf4a22be3c955ac49da2e2107b67a' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2005-05-20 03:29:56 +02:00
|
|
|
select md5(''::bytea) = 'd41d8cd98f00b204e9800998ecf8427e' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('a'::bytea) = '0cc175b9c0f1b6a831c399e269772661' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('abc'::bytea) = '900150983cd24fb0d6963f7d28e17f72' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('message digest'::bytea) = 'f96b697d7cb7938d525a2f31aaf161d0' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('abcdefghijklmnopqrstuvwxyz'::bytea) = 'c3fcd3d76192e4007dfb496cca67e13b' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'::bytea) = 'd174ab98d277d9f5a5611c2c9f419d9f' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select md5('12345678901234567890123456789012345678901234567890123456789012345678901234567890'::bytea) = '57edf4a22be3c955ac49da2e2107b67a' AS "TRUE";
|
|
|
|
TRUE
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|