Re: Oddities with ANYARRAY - Mailing list pgsql-bugs

From Gregory Stark
Subject Re: Oddities with ANYARRAY
Date
Msg-id 87tzristvh.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Oddities with ANYARRAY  (Decibel! <decibel@decibel.org>)
Responses Re: Oddities with ANYARRAY
List pgsql-bugs
"Decibel!" <decibel@decibel.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

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #3503: Benchmark scripts broken
Next
From: "Peter Koczan"
Date:
Subject: BUG #3504: Some listening sessions never return from writing, problems ensue