Is _ a supported way to create a column of array type?

Поиск
Список
Период
Сортировка
От Piotr Findeisen
Тема Is _ a supported way to create a column of array type?
Дата
Msg-id CAMrFzbt_DjD1BSLOhAUgNApu8MV3CCPmbEac9FfMxOOq6GAD0g@mail.gmail.com
обсуждение исходный текст
Ответы Re: Is _ a supported way to create a column of array type?
Список pgsql-general
Дерево обсуждения
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 по дате отправления:

Предыдущее
От: Martin Kováčik
Дата:
Сообщение: Re: analyze causes query planner to choose suboptimal plan for aselect query in separate transaction
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: analyze causes query planner to choose suboptimal plan for aselect query in separate transaction