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@xxxxxxxxx> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment:
signature.asc
Description: Digital signature
