On Thu, Aug 02, 2007 at 12:44:02AM +0100, Gregory Stark wrote: > > "Decibel!" <[EMAIL PROTECTED]> 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.
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. -- Decibel!, aka Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
pgpaDDpUPGFrT.pgp
Description: PGP signature
