Re: [SQL] array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Corey Horton <chorton1(at)austin(dot)rr(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-sql(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [SQL] array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3
Date: 2009-01-21 17:52:55
Message-ID: 200901211752.n0LHqtI23883@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql


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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-01-21 17:54:16 Re: rmgr hooks (v2)
Previous Message Simon Riggs 2009-01-21 17:49:59 Re: Pluggable Indexes (was Re: rmgr hooks (v2))

Browse pgsql-sql by date

  From Date Subject
Next Message Marek Florianczyk 2009-01-23 20:42:44 problem using twice custom comparision operator
Previous Message Bryce Nesbitt 2009-01-20 22:25:18 Re: Way to eliminate pg_dump activity from pg_stat_all ?