On Thu, Dec 26, 2024 at 05:08:36PM -0500, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > So, if users are referencing attndims and the values are not accurate,
> > how useful are they? I was suggesting removal so people would stop
> > relying on inaccurate information, or we correct attndims to be
> > accurate. Allowing people to continue relying on inaccurate information
> > seems like the worst of all options.
>
> 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.
First, my apologies about the URL; it should have been:
https://www.postgresql.org/message-id/zvwi_ozt8z9mc...@momjian.us
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
Interestingly, if I dump and restore with:
$ createdb test2; pg_dump test | sql test2
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.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
