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 09:16
On Wed, Jul 21, 2010 at 8:14 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote:
> 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

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

--
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: David Fetter on 22 Jul 2010 15:16
On Wed, Jul 21, 2010 at 02:38:17PM -0400, Merlin Moncure wrote:
> On Wed, Jul 21, 2010 at 2:28 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
> > Yeah, I'd like some more votes, too. �Aside from what I suggested
> > (array_join/array_split), I think my favorite is your #5.
>
> -1 for me for any name that is of the form of:
> type_operation();
>
> we don't have bytea_encode, array_unnest(), date_to_char(), etc. the
> non-internal ones that we do have (mostly array funcs), are improperly
> named imo. this is sql, not c. suppose we want to extend string
> serialization to row types?
>
> why not serialize/unserialize?

Because that's not what the function actually does.

FWIW, I'm for (im|ex)plode, as join()/split(), which I'd otherwise
like, would run into too many issues with JOIN.

Cheers,
David.
--
David Fetter <david(a)fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter(a)gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
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  | 
Pages: 1 2 3 4 5
Prev: multibyte charater set in levenshtein function
Next: (9.1) btree_gist support for searching on "not equals"