Bruce Momjian <br...@momjian.us> writes:
> I did write a patch in Novemer 2023 to pass the dimension to the layers
> that needed it, but it was considered too much code compared to its
> value:
> https://www.postgresql.org/message-id/zvwi_ozt8z9mc...@momjian.us
Ah, I'd forgotten that discussion. It looks like the main differences
between your patch and mine are
(1) you did nothing about getting a nonzero attndims value for views
and CREATE TABLE AS cases.
(2) you found a way to get pg_dump to preserve attndims, which you
then also applied to psql's \d.
I'm not really thrilled with (2): it's messy and incomplete, and
I'm not entirely sure it won't break some uses of atttypname within
pg_dump. I do think we should try to get to a place where attndims
is guaranteed nonzero for array-typed columns.
I checked the regression database after applying my patch, and see
that this test works:
regression=# select relname, relkind, attname, attndims, typname from
pg_attribute a join pg_type t on (a.atttypid = t.oid) join pg_class c on
(a.attrelid = c.oid) where typsubscript = 'array_subscript_handler'::regproc
and attndims = 0;
relname | relkind | attname | attndims | typname
---------+---------+---------+----------+---------
(0 rows)
but the reverse case not so much:
regression=# select relname, relkind, attname, attndims, typname from
pg_attribute a join pg_type t on (a.atttypid = t.oid) join pg_class c on
(a.attrelid = c.oid) where typsubscript != 'array_subscript_handler'::regproc
and attndims != 0;
relname | relkind | attname | attndims | typname
------------------+---------+---------+----------+---------
gin_test_idx | i | i | 1 | int4
botharrayidx | i | i | 1 | int4
botharrayidx | i | t | 1 | text
gin_relopts_test | i | i | 1 | int4
(4 rows)
I wonder if we should try to fix the GIN AM to avoid that.
The column being indexed is of an array type in these cases, but the
index entries aren't. It seems inconsistent that it sets up the index
column's attndims and atttypid this way.
regards, tom lane
