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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Is _ a supported way to create a column of array type?
Дата
Msg-id 32678.1556228173@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Is _ a supported way to create a column of array type?  (Piotr Findeisen <piotr.findeisen@starburstdata.com>)
Ответы Re: Is _ a supported way to create a column of array type?  (Piotr Findeisen <piotr.findeisen@starburstdata.com>)
Список pgsql-general
Piotr Findeisen <piotr.findeisen@starburstdata.com> writes:
> I think I need to provide some context for my question.
> ...
> When accessing a table in Postgres, we need to map columns' types to
> appropriate types in Presto.
> For mapping arrays, we need to know number of array dimensions.
> Currently we read this from pg_attribute.attndims and this does not work
> for _<type> columns.

Well, you've got a conceptual problem there, which is exactly the
assumption that attndims is meaningful :-(.

In the first place, the Postgres type system doesn't distinguish
arrays of different numbers of dimensions, ie, int4[][] is not
really different from int4[].  So you can't attach any very strong
meaning to attndims = 2 vs attndims = 1.

In the second place, we don't bother to fill attndims when the
user doesn't write any brackets, which is what would happen with
a type spec of "_int4" rather than "int4[]".  So I guess you could
say that what attndims records is the number of brackets that were
written in the table creation command, but that unfortunately has
got no real semantic significance.

The right way (TM) to decide if a column is of array type is to
look at the pg_type entry its atttypid points at and see if that
is an array type.  Depending on what you want to do, any of these
tests on the pg_type entry might be reasonable:
1. has nonzero typelem.  (This basically means that the column can
   be subscripted, so it includes fixed-length "array" types such
   as "point", which you might not want to accept.)
2. has nonzero typelem and typlen = -1.  (This restricts it to
   varlena arrays, which are the generic kind of array.)
3. has typcategory "A".  (This should be effectively the same
   as method 2, I think, though the backend code doesn't rely
   on typcategory for such decisions.  Conceivably you'd do this
   if you wanted to let users mark weird types as being arrays.)

> 2. is it possible to make pg_attribute.attndims have correct value when
> column is defined using _<type> form?

Even if we wanted to put work into a column that's so vestigial that
taking it out is a reasonable proposal, we would certainly never
back-patch such a change; nor would existing catalog entries change
even if we did.  So you pretty much have to deal with the facts on
the ground, which are that attndims is largely useless.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Piotr Findeisen
Дата:
Сообщение: Re: Is _ a supported way to create a column of array type?
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: analyze causes query planner to choose suboptimal plan for aselect query in separate transaction