Re: Oddities with ANYARRAY
От | Decibel! |
---|---|
Тема | Re: Oddities with ANYARRAY |
Дата | |
Msg-id | 20070804170115.GL25704@nasby.net обсуждение исходный текст |
Ответ на | Re: Oddities with ANYARRAY (Gregory Stark <stark@enterprisedb.com>) |
Список | 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 по дате отправления: