Postgres Pro
Downloads
Home   >   mailing lists

Is _ a supported way to create a column of array type? - Mailing list pgsql-general

From Piotr Findeisen
Subject Is _ a supported way to create a column of array type?
Date
Msg-id CAMrFzbt_DjD1BSLOhAUgNApu8MV3CCPmbEac9FfMxOOq6GAD0g@mail.gmail.com
Whole thread Raw
Responses Re: Is _ a supported way to create a column of array type?
List pgsql-general
Tree view
Hi,

As documented to https://www.postgresql.org/docs/11/arrays.html#ARRAYS-DECLARATION one can create column of an array type using `<typename>[]` form.

Internally, array types get a name in the form of `_<typename>`. 

So -- the question: 
Can a user use `_<typename>` to define a column of array type?
Is it supported?

The reason I am asking is that e.g. int4[] and _int4 behave differently.
Although they look the same, the have different pg_attribute.attndims.

I am testing on Postgres 11.2.

================================================
create table t(a int4[], b _int4);

\d t
                  Table "public.t"
 Column |   Type    | Collation | Nullable | Default
--------+-----------+-----------+----------+---------
 a      | integer[] |           |          |
 b      | integer[] |           |          |


SELECT attname,  attndims FROM pg_attribute att JOIN pg_class tbl ON tbl.oid = att.attrelid WHERE tbl.relname = 't';
 attname  | attndims
----------+----------
...
 a        |        1
 b        |        0
================================================

This has also been discussed previously in 2006 in the https://www.postgresql.org/message-id/8C5B026B51B6854CBE88121DBF097A8651DB95%40ehost010-33.exch010.intermedia.net user group thread. However, it was a while ago (so something might have changed since then) and the conclusion from that discussion wasn't fully clear to me.


Best regards,
Piotr



pgsql-general by date:

Previous
From: Martin Kováčik
Date:
Subject: Re: analyze causes query planner to choose suboptimal plan for aselect query in separate transaction
Next
From: Adrian Klaver
Date:
Subject: Re: analyze causes query planner to choose suboptimal plan for aselect query in separate transaction