Re: BUG #7550: NULL result when coercing a subquery result into an array

I can't seem to reproduce this on a Ubuntu box on 9.1 or 9.2, nor can
I seem to reproduce this with less than ~8 million rows on a windows
one. I can reliably reproduce this with that many rows and the
database dump is only ~120mb so if anyone is interested I can host it
for them, otherwise I guess its not that serious or interesting.

Out of interest is there a debug build I can install or any steps I
can take to investigate this? I'm just pretty curious as to why this
would be occurring.

~Tom

On Mon, Sep 17, 2012 at 9:44 PM, tom Tom <tom(at)tomforb(dot)es> wrote:
> Ok, I will try. I apologize, I made a mistake in the original post:
> 'J. P. Bickella' returns the correct array and 'J. P. Bickell' returns
> NULL. That's what you get for posting in a hurry!
>
> This is the first time I have run this query, so I don't know if it
> affects previous versions.
>
> ~Tom
>
> On Mon, Sep 17, 2012 at 9:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> tom(at)tomforb(dot)es writes:
>>> I have two queries:
>>> http://pgsql.privatepaste.com/7d1473defa
>>> http://pgsql.privatepaste.com/85e1d43b7a
>>
>>> The first query returns NULL and the second one returns an int[] with 623
>>> elements in it. The only difference between the two queries is the last
>>> string - 'J. P. Bickella' returns NULL and 'J. P. Bickell' returns an
>>> int[].
>>
>> That's ... bizarre. I assume you were running this same query without
>> issues on earlier PG versions? Which?
>>
>>> If needed I can host the database this query is executing on for people to
>>> download upon request, but it is 1.2gb in size.
>>
>> I suspect that you could reproduce the problem with a much smaller
>> extract from the table, perhaps a couple thousand rows. Please try
>> to create a self-contained test case along those lines --- it'll be
>> easier all around than dealing with 1GB of data.
>>
>> regards, tom lane