Prev: multibyte charater set in levenshtein function
Next: (9.1) btree_gist support for searching on "not equals"
From: Robert Haas on 21 Jul 2010 07:58
On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote:
> 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.

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

--
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 08:10
2010/7/21 Robert Haas <robertmhaas(a)gmail.com>:
> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote:
>> 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.
>
> 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(a)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
>
>> 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
>

--
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 08:14
2010/7/21 Pavel Stehule <pavel.stehule(a)gmail.com>:
> 2010/7/21 Robert Haas <robertmhaas(a)gmail.com>:
>> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote:
>>> 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.
>>
>> 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(a)postgresql.org/msg151475.html

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

Regards

Pavel


>>
>>> 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(a)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
>>
>>> 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
>>
>

--
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 09:39
> 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

> --
> 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: Robert Haas on 21 Jul 2010 11:55
On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule <pavel.stehule(a)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

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