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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
