> 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
