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

From: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Corey Horton <chorton1(at)austin(dot)rr(dot)com>, "pgsql-sql(at)postgresql(dot)org" <pgsql-sql(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3
Date: 2008-12-14 00:52:28
Message-ID: 38DFB08B-7282-4D6A-8F23-A1EED97AF695@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Huh, I didn't realize that ever worked in the past. I thought the way
to do what the op describes was to cast it to text[] or whatever
datatype you from out-of-band knowledge to expect.

--
Greg

On 13 Dec 2008, at 19:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Corey Horton <chorton1(at)austin(dot)rr(dot)com> writes:
>> I'm trying to use array_to_string on the pg_stats column
>> histogram_bounds...
>> test83=# select array_to_string(histogram_bounds::anyarray, '-') from
>> pg_stats where attname = 'id' and tablename = 'widgets';
>> ERROR: argument declared "anyarray" is not an array but type
>> anyarray
>> In 8.1, it worked fine...
>
> Hmm. This seems to have been broken in this patch:
> http://archives.postgresql.org/pgsql-committers/2008-01/msg00173.php
> which was in response to this complaint:
> http://archives.postgresql.org/pgsql-bugs/2008-01/msg00029.php
> and was attempting to prevent that same failure message in a different
> context :-(. I guess we forgot that pg_statistic makes it possible
> that
> the *actual* datatype passed to a function could be anyarray.
>
> 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.
>
> Are we prepared to re-open what could be at least a risk of crashing
> bugs, in order to support this type of usage? I have to admit that
> it's nice to be able to process the pg_statistic columns like this
> --- I've done it myself. And we'd not heard any reports of problems
> with it before 8.3.
>
> regards, tom lane
>
> --
> Sent via pgsql-sql mailing list (pgsql-sql(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-14 01:10:09 Re: array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3
Previous Message Tom Lane 2008-12-14 00:42:46 Re: Future request: BgBouncer && "cache lookup failed for function": Auto recache function.

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2008-12-14 01:10:09 Re: array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3
Previous Message Tom Lane 2008-12-14 00:38:25 Re: [SQL] array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3