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
signature.asc
Description: PGP signature
