Hi,
This reproduces on master, and zero is only one of the positions that
differ. citext's split_part() splits with a case-insensitive regular
expression and subscripts the resulting array, so it was left behind
when ec0294fb2c8 (v14) taught the core split_part() negative positions.
On master:
- split_part('a,b,c'::citext, ',', -1): NULL, core returns 'c'
- split_part('a,b,c'::citext, ',', 4): NULL, core returns ''
- split_part('a,b,c'::citext, ',', 0): NULL, core raises an error
- split_part('abc'::citext, '', 1): 'a', core returns 'abc'
The last one is the empty delimiter: the regular expression splits
between every character, while the core function treats the whole
string as the only field.
The attached patch keeps the case-insensitive split and applies the
core rules to the result: a negative position counts from the end, a
position past the last field gives an empty string. A zero position
and an empty delimiter, which have no case to ignore, are passed to
the core function, so the error message is the same. Since the
function is part of the extension script, this needs citext 1.9.
Tested on master:
- the citext regression tests pass, with new cases for all of the above;
- ALTER EXTENSION citext UPDATE TO '1.9' changes the -1 case from NULL
to 'c' in an existing database;
- on 20000 random lower-case strings, delimiters of up to three
characters (some of them regex metacharacters) and positions from -6
to 6, the result matches the core split_part() in every case.
Regards,
Manu
