pgsql-server/ oc/src/sgml/func.sgml rc/include ... - Mailing list pgsql-committers

From momjian@postgresql.org (Bruce Momjian - CVS)
Subject pgsql-server/ oc/src/sgml/func.sgml rc/include ...
Date
Msg-id 20020912002125.A388D476946@postgresql.org
Whole thread Raw
List pgsql-committers
CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    momjian@postgresql.org    02/09/11 20:21:25

Modified files:
    doc/src/sgml   : func.sgml
    src/include/catalog: pg_proc.h
    src/test/regress/expected: strings.out
    src/test/regress/sql: strings.sql

Log message:
    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


pgsql-committers by date:

Previous
From: momjian@postgresql.org (Bruce Momjian - CVS)
Date:
Subject: pgsql-server/doc TODO
Next
From: momjian@postgresql.org (Bruce Momjian - CVS)
Date:
Subject: pgsql-server/src pl/plpgsql/src/pl_comp.c pl/p ...