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
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() |