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 <dire...@gmail.com>: > On 17 July 2010 04:52, Pavel Stehule <pavel.steh...@gmail.com> wrote: >> 2010/7/16 Brendan Jurd <dire...@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 >
arraytext.diff
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
