Обсуждение: Please rename split(text,text,int) to splitpart
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
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
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, Pennsylvania19073
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 > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Bruce Momjian > Sent: Wednesday, 11 September 2002 10:33 AM > To: Hannu Krosing > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Please rename split(text,text,int) to splitpart > > > > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
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, Pennsylvania19073
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, Pennsylvania19073
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