Prev: multibyte charater set in levenshtein function
Next: (9.1) btree_gist support for searching on "not equals"
From: Itagaki Takahiro on 12 Jul 2010 03:31
2010/7/12 Pavel Stehule <pavel.stehule(a)gmail.com>:
> I prefere a new names  - because there are a new behave - with little
> bit better default handling of NULL values. string_to_array and
> array_to_string just ignore NULL values - what isn't correct behave.
> Later we can mark these functions as deprecated and remove it. If I
> use current function, then we have to continue in current behave.

I prefer existing names because your new default behavior can be done
with suitable nullstr values. IMHO, new names will be acceptable only if
they are listed in the SQL-standard or many other databases use the
names. Two similar versions of functions must confuse users.

Also, are there any consensus about "existing functions are not correct" ?
Since string_agg() and your new concat() functions ignores NULLs,
I think it is not so bad for array_to_string() to ignore NULLs.

--
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 12 Jul 2010 03:34
some note

2010/7/12 Pavel Stehule <pavel.stehule(a)gmail.com>:
> 2010/7/12 Itagaki Takahiro <itagaki.takahiro(a)gmail.com>:
>> https://commitfest.postgresql.org/action/patch_view?id=300
>>
>> Why did you add to_string() and to_array() functions though we already
>> have string_to_array() and array_to_string() functions?  I prefer adding
>> three arguments version of string_to_array() instead of to_array().
>> Please notice me if you think to_string() and to_array() are better names
>> for the feature. For example, compatibility for other databases.
>>
>
> I prefere a new names  - because there are a new behave - with little
> bit better default handling of NULL values. string_to_array and
> array_to_string just ignore NULL values - what isn't correct behave.

it is related to time where pg arrays doesn't support a NULL. From 8.3
pg array can have a NULL values, but there wasn't any equal changes to
string_to_array and array_to_string functions - so these functions are
not "actual".

pavel


> Later we can mark these functions as deprecated and remove it. If I
> use current function, then we have to continue in current behave.
>
>> * string_to_array( str text, sep text, nullstr text DEFAULT NULL )
>> is compatible with the existing  string_to_array( str, sep ), and
>> "nullstr => 'NULL'" will be same as your to_array().
>>
>> * array_to_string( arr anyarray, sep text, nullstr text DEFAULT NULL )
>> is compatible with the existing  array_to_string(); separator also ignored
>> when nullstr is NULL. "nullstr => ''" (an empty string) will be same as
>> your to_array().
>>
>
> so reason for these new names are different default behave. And we
> can't to change of default behave of existing 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: Pavel Stehule on 12 Jul 2010 04:33
2010/7/12 Itagaki Takahiro <itagaki.takahiro(a)gmail.com>:
> 2010/7/12 Pavel Stehule <pavel.stehule(a)gmail.com>:
>> I prefere a new names  - because there are a new behave - with little
>> bit better default handling of NULL values. string_to_array and
>> array_to_string just ignore NULL values - what isn't correct behave.
>> Later we can mark these functions as deprecated and remove it. If I
>> use current function, then we have to continue in current behave.
>
> I prefer existing names because your new default behavior can be done
> with suitable nullstr values. IMHO, new names will be acceptable only if
> they are listed in the SQL-standard or many other databases use the
> names. Two similar versions of functions must confuse users.

there is different default behave. So if you don't need to use a third argument

>
> Also, are there any consensus about "existing functions are not correct" ?
> Since string_agg() and your new concat() functions ignores NULLs,
> I think it is not so bad for array_to_string() to ignore NULLs.

string_agg is a aggregate function - there are NULLS ignored usually,
concat simulate MySQL behave - and more, there are not problem to use
a coalesce function. string_to_arrays and array_to string are
different - there you cannot use a coalesce. Why string_to_array and
array_to_strings are not correct? a) what is correct sample of using a
array_to_string with NULL ignoring?? Usually, when you have a NULL in
array, you don't want to loose this value. b) for me - these functions
are some of serialisation/deserialisation functions - usually people
don't want to miss any value.

I searching in history - my first proposal was similar to your:

http://www.mail-archive.com/pgsql-hackers(a)postgresql.org/msg151474.html
http://www.mail-archive.com/pgsql-hackers(a)postgresql.org/msg151503.html !!

if you look on this thread, you can see so I was unsure and confused
too - but now I inclinded to Merlin's proposal

shortly:
* string_to_array/array_to_string ignore nulls
* others not aggregates not ignore nulls
* default for NULL isn't "NULL" but empty string - like csv

regards

Pavel Stěhule




>
> --
> 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: Itagaki Takahiro on 12 Jul 2010 02:31
https://commitfest.postgresql.org/action/patch_view?id=300

Why did you add to_string() and to_array() functions though we already
have string_to_array() and array_to_string() functions? I prefer adding
three arguments version of string_to_array() instead of to_array().
Please notice me if you think to_string() and to_array() are better names
for the feature. For example, compatibility for other databases.

* string_to_array( str text, sep text, nullstr text DEFAULT NULL )
is compatible with the existing string_to_array( str, sep ), and
"nullstr => 'NULL'" will be same as your to_array().

* array_to_string( arr anyarray, sep text, nullstr text DEFAULT NULL )
is compatible with the existing array_to_string(); separator also ignored
when nullstr is NULL. "nullstr => ''" (an empty string) will be same as
your to_array().

--
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 12 Jul 2010 02:51
2010/7/12 Itagaki Takahiro <itagaki.takahiro(a)gmail.com>:
> https://commitfest.postgresql.org/action/patch_view?id=300
>
> Why did you add to_string() and to_array() functions though we already
> have string_to_array() and array_to_string() functions?  I prefer adding
> three arguments version of string_to_array() instead of to_array().
> Please notice me if you think to_string() and to_array() are better names
> for the feature. For example, compatibility for other databases.
>

I prefere a new names - because there are a new behave - with little
bit better default handling of NULL values. string_to_array and
array_to_string just ignore NULL values - what isn't correct behave.
Later we can mark these functions as deprecated and remove it. If I
use current function, then we have to continue in current behave.

> * string_to_array( str text, sep text, nullstr text DEFAULT NULL )
> is compatible with the existing  string_to_array( str, sep ), and
> "nullstr => 'NULL'" will be same as your to_array().
>
> * array_to_string( arr anyarray, sep text, nullstr text DEFAULT NULL )
> is compatible with the existing  array_to_string(); separator also ignored
> when nullstr is NULL. "nullstr => ''" (an empty string) will be same as
> your to_array().
>

so reason for these new names are different default behave. And we
can't to change of default behave of existing 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

 |  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"