patch: to_string, to_array functions

On 6 May 2010 04:42, Pavel Stehule <pavel.stehule@gmail.com> wrote:

attached patch contains to_string and to_array functions. These
functions are equivalent of array_to_string and string_to_array
function with maybe more correct NULL handling.

Hi Pavel,

I am reviewing your patch for the commitfest.

Overall the patch looks good, although there were some bogus
whitespace changes in the patch and some messy punctuation/grammar in
some of the code comments. I also thought it was worth mentioning in
the docs the default value for null_string is ''. I made an attempt
to clean those items up and have attached a v2 of the patch.

Regarding the behaviour of the third argument (null_string), I was a
little surprised by the results when I passed in a NULL.

postgres=# select to_string(array['a', 'b', 'c', 'd'], '/', NULL);
to_string
-----------

Now, if the array had some NULL elements in it, I could understand why
the resulting string would be NULL (because str || NULL is NULL), but
in this case there are no NULLs. Why is the result NULL? Surely it
should be 'a/b/c/d' regardless of how the third parameter is set?

In the reverse case:

postgres=# select to_array('a/b/c/d', '/', NULL);
to_array
----------

(1 row)

Again I find this a bit weird. I have left the null_string NULL,
which means it is unknown. It can't possibly match any value in the
string, so effectively passing in a NULL null_string should mean that
the user doesn't want any string items whatsoever to translate into
NULLs in the resulting array. I would expect this call to return
{a,b,c,d}.

Cheers,
BJ

Hello

2010/7/16 Brendan Jurd <direvus@gmail.com>:

On 6 May 2010 04:42, Pavel Stehule <pavel.stehule@gmail.com> wrote:

attached patch contains to_string and to_array functions. These
functions are equivalent of array_to_string and string_to_array
function with maybe more correct NULL handling.

Hi Pavel,

I am reviewing your patch for the commitfest.

Overall the patch looks good, although there were some bogus
whitespace changes in the patch and some messy punctuation/grammar in
some of the code comments.  I also thought it was worth mentioning in
the docs the default value for null_string is ''.  I made an attempt
to clean those items up and have attached a v2 of the patch.

Regarding the behaviour of the third argument (null_string), I was a
little surprised by the results when I passed in a NULL.

postgres=# select to_string(array['a', 'b', 'c', 'd'], '/', NULL);
 to_string
-----------

Now, if the array had some NULL elements in it, I could understand why
the resulting string would be NULL (because str || NULL is NULL), but
in this case there are no NULLs.  Why is the result NULL?  Surely it
should be 'a/b/c/d' regardless of how the third parameter is set?

In the reverse case:

postgres=# select to_array('a/b/c/d', '/', NULL);
 to_array
----------

(1 row)

I didn't thinking about NULL as separator before. Current behave isn't
practical. When default separator is empty string, then NULL can be
used as ignore NULLs - so it can emulate current string_to_array and
array_to_string behave. It can be, because NULL can't be a separator
ever.

select to_string(array[1,2,3,null,5], ',') -> 1,2,3,,5
select to_string(array[1,2,3,null,5], ',', null) -> 1,2,3,5

maybe - next idea and maybe better - we can check NOT NULL for
separator and to add other parameter with default = false -
ignore_null

select to_string(array[1,2,3,null,5], ',', ignore_null := true) -> 1,2,3,5

what do you think?

Regards

Pavel

On 17 July 2010 02:15, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/16 Brendan Jurd <direvus@gmail.com>:

Regarding the behaviour of the third argument (null_string), I was a
little surprised by the results when I passed in a NULL.

I didn't thinking about NULL as separator before. Current behave isn't
practical. When default separator is empty string, then NULL can be
used as ignore NULLs - so it can emulate current string_to_array and
array_to_string behave. It can be, because NULL can't be a separator
ever.

select to_string(array[1,2,3,null,5], ',') -> 1,2,3,,5
select to_string(array[1,2,3,null,5], ',', null) -> 1,2,3,5

maybe - next idea and maybe better - we can check NOT NULL for
separator and to add other parameter with default = false -
ignore_null

select to_string(array[1,2,3,null,5], ',', ignore_null := true) -> 1,2,3,5

what do you think?

I don't have any problem with null_string = NULL in to_string taking
the meaning "skip over NULL elements". It's a slightly strange
outcome but it's more useful than returning NULL, and I do like that
it gives us a path to the current array_to_string() treatment even if
those functions are ultimately deprecated. I think adding a fourth
keyword argument might be sacrificing a little too much convenience in
the calling convention.

As for to_array, null_string = NULL should mean that there is no
string which should result in a NULL element. So I would be happy to
see the following set of behaviours:

to_string(array[1, 2, 3, 4, 5], ',', null) = '1,2,3,4,5'
to_string(array[1, 2, 3, null, 5], ',', null) = '1,2,3,5'
to_array('1,2,3,,5', ',', null) = '{1,2,3,"",5}'

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:

to_array('1,2,3,4,5', null) = '{"1,2,3,4,5"}'
to_string(array[1,2,3,4,5], null) = ERROR: the field separator for
to_string may not be NULL

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.

Cheers,
BJ

2010/7/16 Brendan Jurd <direvus@gmail.com>:

On 17 July 2010 02:15, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/16 Brendan Jurd <direvus@gmail.com>:

Regarding the behaviour of the third argument (null_string), I was a
little surprised by the results when I passed in a NULL.

I didn't thinking about NULL as separator before. Current behave isn't
practical. When default separator is empty string, then NULL can be
used as ignore NULLs - so it can emulate current string_to_array and
array_to_string behave. It can be, because NULL can't be a separator
ever.

select to_string(array[1,2,3,null,5], ',') -> 1,2,3,,5
select to_string(array[1,2,3,null,5], ',', null) -> 1,2,3,5

maybe - next idea and maybe better - we can check NOT NULL for
separator and to add other parameter with default = false -
ignore_null

select to_string(array[1,2,3,null,5], ',', ignore_null := true) -> 1,2,3,5

what do you think?

I don't have any problem with null_string = NULL in to_string taking
the meaning "skip over NULL elements".  It's a slightly strange
outcome but it's more useful than returning NULL, and I do like that
it gives us a path to the current array_to_string() treatment even if
those functions are ultimately deprecated.  I think adding a fourth
keyword argument might be sacrificing a little too much convenience in
the calling convention.

As for to_array, null_string = NULL should mean that there is no
string which should result in a NULL element.  So I would be happy to
see the following set of behaviours:

to_string(array[1, 2, 3, 4, 5], ',', null) = '1,2,3,4,5'
to_string(array[1, 2, 3, null, 5], ',', null) = '1,2,3,5'
to_array('1,2,3,,5', ',', null) = '{1,2,3,"",5}'

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.

to_array('1,2,3,4,5', null) = '{"1,2,3,4,5"}'
to_string(array[1,2,3,4,5], null) = ERROR: the field separator for
to_string may not be NULL

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

Pavel

On 17 July 2010 04:52, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/16 Brendan Jurd <direvus@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

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@gmail.com>:

2010/7/20 Pavel Stehule <pavel.stehule@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

2010/7/21 Itagaki Takahiro <itagaki.takahiro@gmail.com>:

2010/7/20 Pavel Stehule <pavel.stehule@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

On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:

2010/7/20 Pavel Stehule <pavel.stehule@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

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:

2010/7/20 Pavel Stehule <pavel.stehule@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 ?

On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:

2010/7/20 Pavel Stehule <pavel.stehule@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.

But is it really bad enough to introduce custom versions of every
function that might want to do this sort of thing?

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.

But I don't think anyone else agrees with you. The current behavior
isn't the only one anyone might want, but it's one reasonable
behavior.

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

That's not going to reduce confusion one bit...

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

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:

2010/7/20 Pavel Stehule <pavel.stehule@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.

But is it really bad enough to introduce custom versions of every
function that might want to do this sort of thing?

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.

But I don't think anyone else agrees with you.  The current behavior
isn't the only one anyone might want, but it's one reasonable
behavior.

see on discus to these function - this is Marlin Moncure proposal

http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg151503.html

these functions was designed in reaction to reporting bugs and
problems with serialisation and deserialisation of arrays with null
fields.

you can't to parse string to array with null values now

postgres=# select string_to_array('1,2,3,null,5',',')::int[];
ERROR: invalid input syntax for integer: "null"
postgres=#

Regards

Pavel Stehule

2010/7/21 Pavel Stehule <pavel.stehule@gmail.com>:

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:

2010/7/20 Pavel Stehule <pavel.stehule@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.

But is it really bad enough to introduce custom versions of every
function that might want to do this sort of thing?

please look on http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg151475.html

I am not alone in opinion so current string to array functions has
not good design

Regards

Pavel

On Wed, Jul 21, 2010 at 8:14 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/21 Pavel Stehule <pavel.stehule@gmail.com>:

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:

2010/7/20 Pavel Stehule <pavel.stehule@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.

But is it really bad enough to introduce custom versions of every
function that might want to do this sort of thing?

please look on http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg151475.html

I am not alone  in opinion so current string to array functions has
not good design

OK, I stand corrected, although I'm not totally convinced. I still
think to_array() and to_string() are not a good choice of names. I am
not sure if we should reuse the existing names (adding a third
parameter) or pick something else, like array_concat() and
split_to_array().

Also, should we consider putting these in contrib/stringfunc rather
than core? Or is there enough support for core that we should stick
with doing it that way?

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

OK, I stand corrected, although I'm not totally convinced.  I still
think to_array() and to_string() are not a good choice of names.  I am
not sure if we should reuse the existing names (adding a third
parameter) or pick something else, like array_concat() and
split_to_array().

It was discussed before. I would to see some symmetry in names. The
bad thing is so great names like string_to_array and array_to_string
is used, and second bad thing was done three years ago when nobody
thinking about NULL values. I don't think, so we are able to repair
older functions - simply the default behave isn't optimal.

I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first. If these function will be
deprecated, then we can use a similar names (and probably we should to
use a similar names) - so text_to_array or array_to_string can be
acceptable. If not, then this discus is needless - then to_string and
to_array have to be maximally in contrib - stringfunc is good idea -
and maybe we don't need thinking about new names.

Also, should we consider putting these in contrib/stringfunc rather
than core?  Or is there enough support for core that we should stick
with doing it that way?

so it is one variant. I am not against to moving these function to
contrib/stringfunc.

I am thinking, so we have to solve question about marking
string_to_array and array_to_string functions as deprecated first.
Then we can move forward?? My opinion is known - I am for removing of
these function in future and replacing by modernized functions.

Others opinions???

Can we move forward?

Regards

Pavel

On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

It was discussed before. I would to see some symmetry in names.

That's reasonable.

The
bad thing is so great names like string_to_array and array_to_string
is used,

Yeah, those names are not too good.

and second bad thing was done three years ago when nobody
thinking about NULL values. I don't think, so we are able to repair
older functions - simply the default behave isn't optimal.

This is a matter of opinion, but certainly it's not right for everyone.

I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first. If these function will be
deprecated, then we can use a similar names (and probably we should to
use a similar names) - so text_to_array or array_to_string can be
acceptable. If not, then this discus is needless - then to_string and
to_array have to be maximally in contrib - stringfunc is good idea -
and maybe we don't need thinking about new names.

Well, -1 from me for deprecating string_to_array and array_to_string.

I am not in favor of the names to_string and to_array even if we put
them in contrib, though. The problem with string_to_array and
array_to_string is that they aren't descriptive enough, and
to_string/to_array is even less so.

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

On 22 July 2010 01:55, Robert Haas <robertmhaas@gmail.com> wrote:

On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first.

Well, -1 from me for deprecating string_to_array and array_to_string.

For what it's worth, I agree with Pavel about the current behaviour in
core. It's broken whenever NULLs come into play. We need to improve
on this one way or another, and I think it would be a shame to deal
with a problem in core by adding something to contrib.

I am not in favor of the names to_string and to_array even if we put
them in contrib, though.  The problem with string_to_array and
array_to_string is that they aren't descriptive enough, and
to_string/to_array is even less so.

What about implode() and explode()? It's got symmetry and it's
possibly more descriptive.

Cheers,
BJ

2010/7/21 Robert Haas <robertmhaas@gmail.com>:

On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

It was discussed before. I would to see some symmetry in names.

That's reasonable.

The
bad thing is so great names like string_to_array and array_to_string
is used,

Yeah, those names are not too good.

and second bad thing was done three years ago when nobody
thinking about NULL values. I don't think, so we are able to repair
older functions - simply the default behave isn't optimal.

This is a matter of opinion, but certainly it's not right for everyone.

I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first. If these function will be
deprecated, then we can use a similar names (and probably we should to
use a similar names) - so text_to_array or array_to_string can be
acceptable. If not, then this discus is needless - then to_string and
to_array have to be maximally in contrib - stringfunc is good idea -
and maybe we don't need thinking about new names.

Well, -1 from me for deprecating string_to_array and array_to_string.

I am not in favor of the names to_string and to_array even if we put
them in contrib, though.  The problem with string_to_array and
array_to_string is that they aren't descriptive enough, and
to_string/to_array is even less so.

I am not a English native speaker, so I have a different feeling.
These functions do array_serialisation and array_deseralisation, but
this names are too long. I have not idea about better names - it is
descriptive well (for me) text->array, array->text - and these names
shows very cleanly symmetry between functions. I have to repeat - it
is very clean for not native speaker.

On Wed, Jul 21, 2010 at 12:08 PM, Brendan Jurd <direvus@gmail.com> wrote:

On 22 July 2010 01:55, Robert Haas <robertmhaas@gmail.com> wrote:

On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first.

Well, -1 from me for deprecating string_to_array and array_to_string.

For what it's worth, I agree with Pavel about the current behaviour in
core.  It's broken whenever NULLs come into play.  We need to improve
on this one way or another, and I think it would be a shame to deal
with a problem in core by adding something to contrib.

Fair enough. I'm OK with putting it in core if we can come up with
suitable names.

I am not in favor of the names to_string and to_array even if we put
them in contrib, though.  The problem with string_to_array and
array_to_string is that they aren't descriptive enough, and
to_string/to_array is even less so.

What about implode() and explode()?  It's got symmetry and it's
possibly more descriptive.

Hmm, it's a thought.

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