On Thu, Aug 02, 2007 at 12:44:02AM +0100, Gregory Stark wrote:
>=20
> "Decibel!" <decibel@decibel.org> writes:
>=20
> > 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?
>=20
> 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.
>=20
> anyarray and anyelement are things the parser and labels things it doesn't
> know better. Normally that's just parameters of polymorphic functions sin=
ce
> you can't define columns of type anyarray normally. pg_statistic is a mag=
ic
> exception.
>=20
> > 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?
>=20
> 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.
So is ANYARRAY actually a 'real' type in the sense that it remembers the
data type that was passed into it? Or is it more like a label like you
said above?
How horrible would it be to add the ability for an anyarray/anyelement
to know what the original data type was? There's certainly times when
having that ability would be extremely useful; right now people just
fudge it by using text instead.
--=20
Decibel!, aka Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)