Re: Oddities with ANYARRAY - Mailing list pgsql-bugs

From Decibel!
Subject Re: Oddities with ANYARRAY
Date
Msg-id 20070804170115.GL25704@nasby.net
Whole thread Raw
In response to Re: Oddities with ANYARRAY  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-bugs
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)

pgsql-bugs by date:

Previous
From: Decibel!
Date:
Subject: Re: BUG #3499: no owner privileges in information_schema.table_privileges
Next
From: Brian Hirt
Date:
Subject: failed to re-find parent key in "..." for deletion target page