Is there any known workaround to get this the elements of the histogram_bounds anyarray in 8.3.5. If not, when might
Iexpect a fix?<br /><br /> Just trying to plan our testing/release schedule of rolling out to 8.3 around this problem.
<br/><br /> Thanks,<br /> Corey<br /><br /> Tom Lane wrote: <blockquote cite="mid:26729.1229278563@sss.pgh.pa.us"
type="cite"><prewrap="">I wrote: </pre><blockquote type="cite"><pre wrap="">While we could probably revert just enough
ofthe 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. </pre></blockquote><pre wrap="">
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
</pre></blockquote>
