Skip site navigation (1) Skip section navigation (2)

Re: string_to_array with empty input

From: Greg Stark <stark(at)enterprisedb(dot)com>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: string_to_array with empty input
Date: 2009-03-31 16:08:45
Message-ID: 4136ffa0903310908g43a8a733n2abbc12d02d8ba3e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
On Tue, Mar 31, 2009 at 4:34 PM, Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:
>
> That's also a disingenuous example; what would you expect back from:
>
>  select count_elements(string_to_array('butter,,milk',','))
>
> I think the semantics you want is what you'd get from:
>
>  array_filter_blanks(string_to_array($1,$2))
>
> where I defined "array_filter_blanks" in my previous post.

I think you're still thinking from a programmers point of view
thinking about string processing.

From a functional point of view, if I give you a comma separated list
of items which is an empty string and ask you how many items are in it
nobody would normally say there's one empty thing in the list.

Both interpretations are clearly consistent but it depends on whether
you think it's a bunch of text strings concatenated together or if
it's a list of objects.

The example of string_to_array('',',')::int[] is relevant to this
point. The whole "there's one empty element" only makes sense if
you're thinking in terms of string processing. If it's a list of any
other kind of object it probably doesn't make sense; you can't say
there's one empty integer or one empty composite object or one empty
anything else.

-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: justinDate: 2009-03-31 16:11:19
Subject: Re: string_to_array with empty input
Previous:From: Andrew DunstanDate: 2009-03-31 15:59:45
Subject: Re: Partitioning feature ...

pgsql-general by date

Next:From: justinDate: 2009-03-31 16:11:19
Subject: Re: string_to_array with empty input
Previous:From: Scott MarloweDate: 2009-03-31 16:07:34
Subject: Re: Space for pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group