Please rename split(text,text,int) to splitpart

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.

Thanks,

Joe

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.

Please apply.

Thanks,

Joe

What do people think if this change?

---------------------------------------------------------------------------

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.

----------------
Hannu

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

I think it should be made. Don't force an initdb. Beta testers can run the
update. 'split' is a pretty standard function these days...

Chris

Christopher Kings-Lynne wrote:

I think it should be made. Don't force an initdb. Beta testers can run the
update. 'split' is a pretty standard function these days...

Me too. Patch already sent in, including doc and regression test.

And as I said, I'll take a TODO to create a 'split' which either returns an
array or maybe as an SRF, so the behavior is more like people will be expecting.

Joe

Bruce Momjian <pgman@candle.pha.pa.us> writes:

What do people think if this change?

I'm not thrilled about renaming the function without forcing an initdb
... but the alternatives seem worse. Okay by me if we do it.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

What do people think if this change?

I'm not thrilled about renaming the function without forcing an initdb
... but the alternatives seem worse. Okay by me if we do it.

I am not either. How do you do the documentation when the function can
be called two ways. I guess we can give the SQL query to fix it during
beta2 _and_ add a regression test to make sure it is fix. That sounds
like a plan.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Joe Conway wrote:

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.

Please apply.

Thanks,

Joe

Index: src/include/catalog/pg_proc.h
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/include/catalog/pg_proc.h,v
retrieving revision 1.270
diff -c -r1.270 pg_proc.h
*** src/include/catalog/pg_proc.h	4 Sep 2002 20:31:38 -0000	1.270
--- src/include/catalog/pg_proc.h	7 Sep 2002 18:54:57 -0000
***************
*** 2130,2136 ****
DESCR("return portion of string");
DATA(insert OID =  2087 ( replace	   PGNSP PGUID 12 f f t f i 3 25 "25 25 25"  replace_text - _null_ ));
DESCR("replace all occurrences of old_substr with new_substr in string");
! DATA(insert OID =  2088 ( split		   PGNSP PGUID 12 f f t f i 3 25 "25 25 23"  split_text - _null_ ));
DESCR("split string by field_sep and return field_num");
DATA(insert OID =  2089 ( to_hex	   PGNSP PGUID 12 f f t f i 1 25 "23"  to_hex32 - _null_ ));
DESCR("convert int32 number to hex");
--- 2130,2136 ----
DESCR("return portion of string");
DATA(insert OID =  2087 ( replace	   PGNSP PGUID 12 f f t f i 3 25 "25 25 25"  replace_text - _null_ ));
DESCR("replace all occurrences of old_substr with new_substr in string");
! DATA(insert OID =  2088 ( split_part   PGNSP PGUID 12 f f t f i 3 25 "25 25 23"  split_text - _null_ ));
DESCR("split string by field_sep and return field_num");
DATA(insert OID =  2089 ( to_hex	   PGNSP PGUID 12 f f t f i 1 25 "23"  to_hex32 - _null_ ));
DESCR("convert int32 number to hex");
Index: src/test/regress/expected/strings.out
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/test/regress/expected/strings.out,v
retrieving revision 1.16
diff -c -r1.16 strings.out
*** src/test/regress/expected/strings.out	28 Aug 2002 20:18:29 -0000	1.16
--- src/test/regress/expected/strings.out	7 Sep 2002 19:09:44 -0000
***************
*** 719,747 ****
(1 row)

--
! -- test split
--
! select split('joeuser@mydatabase','@',0) AS "an error";
ERROR: field position must be > 0
! select split('joeuser@mydatabase','@',1) AS "joeuser";
joeuser
---------
joeuser
(1 row)

! select split('joeuser@mydatabase','@',2) AS "mydatabase";
mydatabase
------------
mydatabase
(1 row)

! select split('joeuser@mydatabase','@',3) AS "empty string";
empty string
--------------

(1 row)

! select split('@joeuser@mydatabase@','@',2) AS "joeuser";
joeuser 
---------
joeuser
--- 719,747 ----
(1 row)

--
! -- test split_part
--
! select split_part('joeuser@mydatabase','@',0) AS "an error";
ERROR: field position must be > 0
! select split_part('joeuser@mydatabase','@',1) AS "joeuser";
joeuser
---------
joeuser
(1 row)

! select split_part('joeuser@mydatabase','@',2) AS "mydatabase";
mydatabase
------------
mydatabase
(1 row)

! select split_part('joeuser@mydatabase','@',3) AS "empty string";
empty string
--------------

(1 row)

! select split_part('@joeuser@mydatabase@','@',2) AS "joeuser";
joeuser 
---------
joeuser
Index: src/test/regress/sql/strings.sql
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/test/regress/sql/strings.sql,v
retrieving revision 1.10
diff -c -r1.10 strings.sql
*** src/test/regress/sql/strings.sql	28 Aug 2002 20:18:29 -0000	1.10
--- src/test/regress/sql/strings.sql	7 Sep 2002 19:09:00 -0000
***************
*** 288,304 ****
SELECT replace('yabadoo', 'bad', '') AS "yaoo";

--
! -- test split
--
! select split('joeuser@mydatabase','@',0) AS "an error";

! select split('joeuser@mydatabase','@',1) AS "joeuser";

! select split('joeuser@mydatabase','@',2) AS "mydatabase";

! select split('joeuser@mydatabase','@',3) AS "empty string";

! select split('@joeuser@mydatabase@','@',2) AS "joeuser";

--
-- test to_hex
--- 288,304 ----
SELECT replace('yabadoo', 'bad', '') AS "yaoo";

--
! -- test split_part
--
! select split_part('joeuser@mydatabase','@',0) AS "an error";

! select split_part('joeuser@mydatabase','@',1) AS "joeuser";

! select split_part('joeuser@mydatabase','@',2) AS "mydatabase";

! select split_part('joeuser@mydatabase','@',3) AS "empty string";

! select split_part('@joeuser@mydatabase@','@',2) AS "joeuser";

--
-- test to_hex
Index: doc/src/sgml/func.sgml
===================================================================
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.120
diff -c -r1.120 func.sgml
*** doc/src/sgml/func.sgml	2 Sep 2002 05:53:23 -0000	1.120
--- doc/src/sgml/func.sgml	7 Sep 2002 19:12:34 -0000
***************
*** 1899,1912 ****
</row>

<row>
! <entry><function>split</function>(<parameter>string</parameter> <type>text</type>,
<parameter>delimiter</parameter> <type>text</type>,
<parameter>column</parameter> <type>integer</type>)</entry>
<entry><type>text</type></entry>
<entry>Split <parameter>string</parameter> on <parameter>delimiter</parameter>
returning the resulting (one based) <parameter>column</parameter> number.
</entry>
! <entry><literal>split('abc~@~def~@~ghi','~@~',2)</literal></entry>
<entry><literal>def</literal></entry>
</row>

--- 1899,1912 ----
</row>

<row>
! <entry><function>split_part</function>(<parameter>string</parameter> <type>text</type>,
<parameter>delimiter</parameter> <type>text</type>,
<parameter>column</parameter> <type>integer</type>)</entry>
<entry><type>text</type></entry>
<entry>Split <parameter>string</parameter> on <parameter>delimiter</parameter>
returning the resulting (one based) <parameter>column</parameter> number.
</entry>
! <entry><literal>split_part('abc~@~def~@~ghi','~@~',2)</literal></entry>
<entry><literal>def</literal></entry>
</row>

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am not either. How do you do the documentation when the function can
be called two ways.

You don't. There is only one supported name, so that's the only one
you document.

I guess we can give the SQL query to fix it during
beta2 _and_ add a regression test to make sure it is fix. That sounds
like a plan.

That sounds like massive overkill. Just apply the patch. We don't need
to institutionalize a regression test for this.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am not either. How do you do the documentation when the function can
be called two ways.

You don't. There is only one supported name, so that's the only one
you document.

I guess we can give the SQL query to fix it during
beta2 _and_ add a regression test to make sure it is fix. That sounds
like a plan.

That sounds like massive overkill. Just apply the patch. We don't need
to institutionalize a regression test for this.

It would catch people who don't apply the patch. We could remove the
test after 7.3. Just an idea.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Tom Lane wrote:

That sounds like massive overkill. Just apply the patch. We don't need
to institutionalize a regression test for this.

It would catch people who don't apply the patch. We could remove the
test after 7.3. Just an idea.

The existing strings regression test will fail if the update patch isn't applied.

Joe

Patch applied. Thanks.

I have not forced an initdb, _but_ there will be regression failures if
an initdb is not done. The regression test was part of the patch.

---------------------------------------------------------------------------

Joe Conway wrote:

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.

Please apply.

Thanks,

Joe

Index: src/include/catalog/pg_proc.h
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/include/catalog/pg_proc.h,v
retrieving revision 1.270
diff -c -r1.270 pg_proc.h
*** src/include/catalog/pg_proc.h	4 Sep 2002 20:31:38 -0000	1.270
--- src/include/catalog/pg_proc.h	7 Sep 2002 18:54:57 -0000
***************
*** 2130,2136 ****
DESCR("return portion of string");
DATA(insert OID =  2087 ( replace	   PGNSP PGUID 12 f f t f i 3 25 "25 25 25"  replace_text - _null_ ));
DESCR("replace all occurrences of old_substr with new_substr in string");
! DATA(insert OID =  2088 ( split		   PGNSP PGUID 12 f f t f i 3 25 "25 25 23"  split_text - _null_ ));
DESCR("split string by field_sep and return field_num");
DATA(insert OID =  2089 ( to_hex	   PGNSP PGUID 12 f f t f i 1 25 "23"  to_hex32 - _null_ ));
DESCR("convert int32 number to hex");
--- 2130,2136 ----
DESCR("return portion of string");
DATA(insert OID =  2087 ( replace	   PGNSP PGUID 12 f f t f i 3 25 "25 25 25"  replace_text - _null_ ));
DESCR("replace all occurrences of old_substr with new_substr in string");
! DATA(insert OID =  2088 ( split_part   PGNSP PGUID 12 f f t f i 3 25 "25 25 23"  split_text - _null_ ));
DESCR("split string by field_sep and return field_num");
DATA(insert OID =  2089 ( to_hex	   PGNSP PGUID 12 f f t f i 1 25 "23"  to_hex32 - _null_ ));
DESCR("convert int32 number to hex");
Index: src/test/regress/expected/strings.out
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/test/regress/expected/strings.out,v
retrieving revision 1.16
diff -c -r1.16 strings.out
*** src/test/regress/expected/strings.out	28 Aug 2002 20:18:29 -0000	1.16
--- src/test/regress/expected/strings.out	7 Sep 2002 19:09:44 -0000
***************
*** 719,747 ****
(1 row)

--
! -- test split
--
! select split('joeuser@mydatabase','@',0) AS "an error";
ERROR: field position must be > 0
! select split('joeuser@mydatabase','@',1) AS "joeuser";
joeuser
---------
joeuser
(1 row)

! select split('joeuser@mydatabase','@',2) AS "mydatabase";
mydatabase
------------
mydatabase
(1 row)

! select split('joeuser@mydatabase','@',3) AS "empty string";
empty string
--------------

(1 row)

! select split('@joeuser@mydatabase@','@',2) AS "joeuser";
joeuser 
---------
joeuser
--- 719,747 ----
(1 row)

--
! -- test split_part
--
! select split_part('joeuser@mydatabase','@',0) AS "an error";
ERROR: field position must be > 0
! select split_part('joeuser@mydatabase','@',1) AS "joeuser";
joeuser
---------
joeuser
(1 row)

! select split_part('joeuser@mydatabase','@',2) AS "mydatabase";
mydatabase
------------
mydatabase
(1 row)

! select split_part('joeuser@mydatabase','@',3) AS "empty string";
empty string
--------------

(1 row)

! select split_part('@joeuser@mydatabase@','@',2) AS "joeuser";
joeuser 
---------
joeuser
Index: src/test/regress/sql/strings.sql
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/test/regress/sql/strings.sql,v
retrieving revision 1.10
diff -c -r1.10 strings.sql
*** src/test/regress/sql/strings.sql	28 Aug 2002 20:18:29 -0000	1.10
--- src/test/regress/sql/strings.sql	7 Sep 2002 19:09:00 -0000
***************
*** 288,304 ****
SELECT replace('yabadoo', 'bad', '') AS "yaoo";

--
! -- test split
--
! select split('joeuser@mydatabase','@',0) AS "an error";

! select split('joeuser@mydatabase','@',1) AS "joeuser";

! select split('joeuser@mydatabase','@',2) AS "mydatabase";

! select split('joeuser@mydatabase','@',3) AS "empty string";

! select split('@joeuser@mydatabase@','@',2) AS "joeuser";

--
-- test to_hex
--- 288,304 ----
SELECT replace('yabadoo', 'bad', '') AS "yaoo";

--
! -- test split_part
--
! select split_part('joeuser@mydatabase','@',0) AS "an error";

! select split_part('joeuser@mydatabase','@',1) AS "joeuser";

! select split_part('joeuser@mydatabase','@',2) AS "mydatabase";

! select split_part('joeuser@mydatabase','@',3) AS "empty string";

! select split_part('@joeuser@mydatabase@','@',2) AS "joeuser";

--
-- test to_hex
Index: doc/src/sgml/func.sgml
===================================================================
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.120
diff -c -r1.120 func.sgml
*** doc/src/sgml/func.sgml	2 Sep 2002 05:53:23 -0000	1.120
--- doc/src/sgml/func.sgml	7 Sep 2002 19:12:34 -0000
***************
*** 1899,1912 ****
</row>

<row>
! <entry><function>split</function>(<parameter>string</parameter> <type>text</type>,
<parameter>delimiter</parameter> <type>text</type>,
<parameter>column</parameter> <type>integer</type>)</entry>
<entry><type>text</type></entry>
<entry>Split <parameter>string</parameter> on <parameter>delimiter</parameter>
returning the resulting (one based) <parameter>column</parameter> number.
</entry>
! <entry><literal>split('abc~@~def~@~ghi','~@~',2)</literal></entry>
<entry><literal>def</literal></entry>
</row>

--- 1899,1912 ----
</row>

<row>
! <entry><function>split_part</function>(<parameter>string</parameter> <type>text</type>,
<parameter>delimiter</parameter> <type>text</type>,
<parameter>column</parameter> <type>integer</type>)</entry>
<entry><type>text</type></entry>
<entry>Split <parameter>string</parameter> on <parameter>delimiter</parameter>
returning the resulting (one based) <parameter>column</parameter> number.
</entry>
! <entry><literal>split_part('abc~@~def~@~ghi','~@~',2)</literal></entry>
<entry><literal>def</literal></entry>
</row>

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073