Re: BUG #8150: NULL emements lost when casting result of unnest()

From: "Erik Rijkers" <er(at)xs4all(dot)nl>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: brandstetter(at)falter(dot)at, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8150: NULL emements lost when casting result of unnest()
Date: 2013-05-11 15:26:19
Message-ID: e59ef673eb74c805d5156d5ba61813cf.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, May 11, 2013 17:13, Tom Lane wrote:
> brandstetter(at)falter(dot)at writes:
>> SELECT unnest('{1,NULL,4}'::int[])::int8;
>> i
>> ---
>> 1
>> 4
>
>
> This is another case where I'm not too sure if we ought to back-patch.
> The current behavior is clearly wrong, but perhaps some application
> out there will be unhappy if we change it in back branches?
>

My vote would be against backpatching, both in this case and in the recent TO_CHAR()/TO_NUMBER()
format problem.

Perhaps there would be value in making the back branch patches available. (Perhaps these two
patches are already usable against backbranches; I would have tried but I cannot build lower than
9.2 at the moment; I assume no-one can)

Erik Rijkers

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message antreimer 2013-05-11 18:16:28 BUG #8151: client libraries not working on mingw-w64 gcc 4.8
Previous Message Tom Lane 2013-05-11 15:13:44 Re: BUG #8150: NULL emements lost when casting result of unnest()