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
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. |
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 |