Prev: multibyte charater set in levenshtein function
Next: (9.1) btree_gist support for searching on "not equals"
From: Pavel Stehule on 20 Jul 2010 07:42
Hello

here is a new version - new these functions are not a strict and
function to_string is marked as stable.

both functions share code with older version.

Regards

Pavel

2010/7/16 Brendan Jurd <direvus(a)gmail.com>:
> On 17 July 2010 04:52, Pavel Stehule <pavel.stehule(a)gmail.com> wrote:
>> 2010/7/16 Brendan Jurd <direvus(a)gmail.com>:
>>> Also, if we're going to make the function non-strict, we need to
>>> consider how to respond when the user specifies NULL for the other
>>> arguments.  If the field separator is NULL, bearing in mind that NULL
>>> can't match any string, I would expect that to_array would return the
>>> undivided string as a single array element, and that to_string would
>>> throw an error:
>>>
>>
>> ok, it has a sense.
>>
>> other question is empty string as separator - but I think, it can has
>> same behave like string_to_array and array_to_string functions.
>>
>
> Agreed.  Those behaviours seem sensible.
>
>>> If the first argument is NULL for either function, I think it would be
>>> reasonable to return NULL.  But I could be convinced that we should
>>> throw an error in that case too.
>>>
>>
>> I agree - I prefer a NULL
>>
>> Thank You very much
>
> No worries; I will await a revised patch from you which updates these
> behaviours -- please incorporate the doc/comment changes I posted
> earlier -- I will then do a further review before handing off to a
> committer.
>
> Cheers,
> BJ
>
From: Itagaki Takahiro on 21 Jul 2010 00:39
2010/7/20 Pavel Stehule <pavel.stehule(a)gmail.com>:
> here is a new version - new these functions are not a strict and
> function to_string is marked as stable.

We have array_to_string(anyarray, text) and string_to_array(text, text),
and you'll introduce to_string(anyarray, text, text) and
to_array(text, text, text).
Do we think it is good idea to have different names for them? IMHO, we'd
better use 3 arguments version of array_to_string() instead of the
new to_string() ?

If to_string and to_array is in the SQL standard, we can accept the
name changes.
But if there are no standard, I'd like to keep the existing function names.

--
Itagaki Takahiro

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Pavel Stehule on 21 Jul 2010 01:51
2010/7/21 Itagaki Takahiro <itagaki.takahiro(a)gmail.com>:
> 2010/7/20 Pavel Stehule <pavel.stehule(a)gmail.com>:
>> here is a new version - new these functions are not a strict and
>> function to_string is marked as stable.
>
> We have array_to_string(anyarray, text) and string_to_array(text, text),
> and you'll introduce to_string(anyarray, text, text) and
> to_array(text, text, text).

I have to repeat it, the behave of this functions are little bit
different. string_to_array and array_to_string are buggy.

* it isn't support a NULL
* it doesn't differentiate a empty array and NULL
* we cannot to change default behave of existing functions
* array_to_string is badly marked as IMMUTABLE

> Do we think it is good idea to have different names for them?  IMHO, we'd
> better  use 3 arguments version of array_to_string() instead of the
> new to_string() ?
>

> If to_string and to_array is in the SQL standard, we can accept the
> name changes.
> But if there are no standard, I'd like to keep the existing function names.
>

no it isn't in standard, but I am thinking, so we have to gently alone
a old functions

Regards

Pavel Stehule

> --
> Itagaki Takahiro
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 21 Jul 2010 07:28
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
<itagaki.takahiro(a)gmail.com> wrote:
> 2010/7/20 Pavel Stehule <pavel.stehule(a)gmail.com>:
>> here is a new version - new these functions are not a strict and
>> function to_string is marked as stable.
>
> We have array_to_string(anyarray, text) and string_to_array(text, text),
> and you'll introduce to_string(anyarray, text, text) and
> to_array(text, text, text).
> Do we think it is good idea to have different names for them? �IMHO, we'd
> better �use 3 arguments version of array_to_string() instead of the
> new to_string() ?

The worst part is that the new names are not very mnemonic.

I think maybe what we really need here is array equivalents of
COALESCE() and NULLIF(). It looks like the proposed to_string()
function is basically equivalent to replacing each NULL entry with the
array with a given value, and then doing array_to_string() as usual.
And it looks like the proposed to_array function basically does the
same thing as to_array(), and then replaces empty strings with NULL or
some other value.

Maybe we just need a function array_replace(anyarray, anyelement,
anyelement) that replaces any element in the array that IS NOT
DISTINCT FROM $2 with $3 and returns the new array. That could be
useful for other things besides this particular case, too.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Pavel Stehule on 21 Jul 2010 07:39
2010/7/21 Robert Haas <robertmhaas(a)gmail.com>:
> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
> <itagaki.takahiro(a)gmail.com> wrote:
>> 2010/7/20 Pavel Stehule <pavel.stehule(a)gmail.com>:
>>> here is a new version - new these functions are not a strict and
>>> function to_string is marked as stable.
>>
>> We have array_to_string(anyarray, text) and string_to_array(text, text),
>> and you'll introduce to_string(anyarray, text, text) and
>> to_array(text, text, text).
>> Do we think it is good idea to have different names for them?  IMHO, we'd
>> better  use 3 arguments version of array_to_string() instead of the
>> new to_string() ?
>
> The worst part is that the new names are not very mnemonic.
>
> I think maybe what we really need here is array equivalents of
> COALESCE() and NULLIF().  It looks like the proposed to_string()
> function is basically equivalent to replacing each NULL entry with the
> array with a given value, and then doing array_to_string() as usual.
> And it looks like the proposed to_array function basically does the
> same thing as to_array(), and then replaces empty strings with NULL or
> some other value.
>
> Maybe we just need a function array_replace(anyarray, anyelement,
> anyelement) that replaces any element in the array that IS NOT
> DISTINCT FROM $2 with $3 and returns the new array.  That could be
> useful for other things besides this particular case, too.
>

I don't agree. Building or updating any array is little bit expensive.
There can be same performance issue like combination array_agg and
array_to_string versus string_agg. I am not against to possible name
changes. But I am strong in opinion so current string_to_array and
array_to_string are buggy and have to be deprecated.

Regards

Pavel

p.s. can we use a names - text_to_array, array_to_text ?


> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: multibyte charater set in levenshtein function
Next: (9.1) btree_gist support for searching on "not equals"