On Mon, Oct 16, 2006 at 01:16:34PM -0700, George Pavlov wrote:
> 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).
Hmm, if someone typos to get "int8" instead of "int4" they get the
wrong datatype too, I don't know if that's an argument. The reason is
that all types need to have an identifier. I suppose they could be
called "pg_internal_array_type_for_int4", but for historical reasons
it's just _int4.
It's deprecated, you're not encouraged to use it and if it were easy to
get rid of it would have been done a long time ago.
> Not sure what you mean--char(x) is not an oddity and it does have array
> support:
The types char, integer, real, etc are the SQL names for the types and
they have special SQL incantations for them. The underlying types are
actually called bpchar, int4 and float8. The latter have magic array
types, the former don't.
> create table a7 (b char(1)[]);
> CREATE TABLE
This is just another way of saying:
create table a7 (b _bpchar)
except that doesn't allow you to specify a length...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
