FYI, I tested your query in 8.3.X CVS and it worked so this fix will in the next 8.3 minor release.
--------------------------------------------------------------------------- Corey Horton wrote: > Is there any known workaround to get this the elements of the > histogram_bounds anyarray in 8.3.5. If not, when might I expect a fix? > > Just trying to plan our testing/release schedule of rolling out to 8.3 > around this problem. > > Thanks, > Corey > > Tom Lane wrote: > > I wrote: > > > >> While we could probably revert just enough of the changes to > >> enforce_generic_type_consistency to allow this case again, I wonder > >> just how safe that'd really be. It would amount to expecting that > >> functions that take anyarray but don't take or return anyelement to > >> not only work on any array type, but to be always prepared for the > >> input element type to change on-the-fly (since that's exactly what > >> would happen when scanning pg_statistic). Quite a lot of the built-in > >> anyarray functions are prepared to do that, but I'm not sure they all > >> are. > >> > > > > I went and looked, and found that none of the thirty or so built-in > > functions that accept ANYARRAY are coded to make unsafe assumptions > > about the input array type remaining the same across calls. So at least > > as of CVS HEAD, it seems safe to relax this back to the way it was > > pre-8.3. > > > > I'm still worried about the possibility of extension functions or future > > core functions failing to follow this coding rule; but as long as people > > are lazy and copy-and-paste from the existing models, it should be okay. > > > > regards, tom lane > > > > > > -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
