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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Piotr Findeisen <piotr(dot)findeisen(at)starburstdata(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Is _<typename> a supported way to create a column of array type?
Date: 2019-04-25 21:36:13
Message-ID: 32678.1556228173@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Piotr Findeisen <piotr(dot)findeisen(at)starburstdata(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2019-04-25 22:25:43 Re: analyze causes query planner to choose suboptimal plan for a select query in separate transaction
Previous Message Piotr Findeisen 2019-04-25 21:17:00 Re: Is _<typename> a supported way to create a column of array type?