From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Decibel!" <decibel(at)decibel(dot)org> |
Cc: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Oddities with ANYARRAY |
Date: | 2007-08-01 23:44:02 |
Message-ID: | 87tzristvh.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Decibel!" <decibel(at)decibel(dot)org> writes:
> On Jul 31, 2007, at 11:55 PM, Gregory Stark wrote:
>>
>> And what type would the result be?
>
> ANYELEMENT? I know that'd still have to be casted to something normal
> eventually; do we have support for that?
There isn't really any such thing. There isn't really any such thing as
anyarray either, the actual arrays are normal arrays of a real data type.
anyarray and anyelement are things the parser and labels things it doesn't
know better. Normally that's just parameters of polymorphic functions since
you can't define columns of type anyarray normally. pg_statistic is a magic
exception.
> I'd expected that the 'ANY' types had additional information somewhere that told
> them what the original data type actually was, but I guess that's not the case.
> Maybe it'd be worth adding?
Well arrays do. That's the only reason we can output the arrays from
pg_statistic. So we could cast an anyarray to an array of a specific data
type. The parser would be able to make sense of (histogram_bounds::text[])[1]
since it's obviously a text.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-08-02 08:03:57 | Re: BUG #3504: Some listening sessions never return from writing, problems ensue |
Previous Message | Bruce Momjian | 2007-08-01 22:25:08 | Re: BUG #3503: Benchmark scripts broken |