> Yep, the array type is represented internally by prefixings an > underscore. It's mentioned somewhere in the docs, but you may as well > ignore it. Hmm, I am not sure I particularly like this behavior or the "ignore it" advice. Suppose someone makes a typo in his/her table definition: meant to create an int4 column but accidentally typed an underscore. You'd expect the statement to fail. Instead it doesn't fail but creates an unexpected datatype for the column. If undescore is a purposeful (rather than an accidental) SQL standard extension one would expect it to be (a) documented in some place like http://www.postgresql.org/docs/8.1/static/arrays.html#AEN5584, and (b) behaving more consistently (if _foo is a synonym for foo[] then all variations of "foo" should support it). > "int4" is the actual type name, "integer" is the sql standard name. > PostgreSQL displays SQL compliant output where possible. _int simply > doesn't exist, and oddities like (3) after the char does have array > support at all... Not sure what you mean--char(x) is not an oddity and it does have array support: create table a7 (b char(1)[]); CREATE TABLE George
