On Thu, Jun 20, 2013 at 07:13:48PM -0500, Merlin Moncure wrote: > On Thu, Jun 20, 2013 at 6:40 PM, Bruce Momjian <br...@momjian.us> wrote: > >> Kinda -- what I'm saying is you just don't go around changing function > >> behaviors to make them 'better' unless the affected behavior was > >> specifically reserved as undefined. The fact is nobody knows how many > >> users will be affected and the extent of the ultimate damage (pro tip: > >> it's always more and worse than expected); I'm astonished it's even > >> being considered. > > > > Well, I think the question is how many people have such arrays that will > > be effected. If we don't do something, we live with this odd behavior > > forever. We have been willing to make some bold decisions in the past > > to improve user experience, and it mostly has worked out well. I > > disagree that it is always worse than expected. > > Well, you can have the last word (although 'bold' was an interesting > word choice, heh) -- I feel guilty enough about beating up Brendan > already. I feel this way every time compatibility changes come up, so > it's nothing specific to this patch really.
Well, sometimes we underestimate the impact of changes, sometimes we overestimate. The big problem is weighing the short-term problems of change but not the long-term benefit of a change. This array problem goes back to at least 2008: http://www.postgresql.org/message-id/28026.1224611...@sss.pgh.pa.us so we have at least five years of confusion by not changing it then. I am not saying we need to change it, but do think we need to weigh both issues. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers