Re: attndims, typndims still not enforced, but make the value within a sane threshold

On Thu, Dec 26, 2024 at 06:07:45PM -0500, Bruce Momjian wrote:
> On Thu, Dec 26, 2024 at 05:08:36PM -0500, Tom Lane wrote:
>> I think removal is not happening. The documentation for attndims
>> already says
>>
>> Number of dimensions, if the column is an array type; otherwise
>> 0. (Presently, the number of dimensions of an array is not
>> enforced, so any nonzero value effectively means “it's an array”.)
>>
>> and as far as I know that is completely correct. (Hence, your gripe
>> is not that it's not "accurate", rather that it's not "precise".)
>>
>> There isn't a comparable disclaimer under typndims, but there probably
>> should be.

FWIW, basically all application I've seen rely on attndims and typndims to
do non-zero comparison to save in joins with other catalogs.

> Using the queries in that URL, I see:
>
> CREATE TABLE test (data integer, data_array integer[5][5]);
> CREATE TABLE test2 (LIKE test);
> CREATE TABLE test3 AS SELECT * FROM test;
> SELECT relname, attndims
> FROM pg_class JOIN pg_attribute ON (pg_attribute.attrelid = pg_class.oid)
> WHERE attname = 'data_array';
>
> relname | attndims
> ---------+----------
> test | 2
> --> test2 | 0
> --> test3 | 0

Ugh. LIKE and CTAS are wrong here with what they add in pg_attribute.

> and run the query again I get:
>
> SELECT relname, attndims
> FROM pg_class JOIN pg_attribute ON (pg_attribute.attrelid = pg_class.oid)
> WHERE attname = 'data_array';
>
> relname | attndims
> ---------+----------
> test | 1
> test2 | 1
> test3 | 1
>
> There is clearly something not ideal about this behavior.

Still, these are better post-restore.
--
Michael