From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, jian he <jian(dot)universality(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: attndims, typndims still not enforced, but make the value within a sane threshold |
Date: | 2025-01-20 19:48:53 |
Message-ID: | Z46opRncDKIb9dgy@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 19, 2025 at 06:47:14PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > 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
>
> Yeah, that's not great. We don't have the ability to extract a
> number-of-dimensions from a result column of a SELECT, but we could
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_ozT8z9MCnIZ@momjian.us
> at least take care to make attndims be 1 not 0 for an array type.
> And CREATE TABLE LIKE can easily do better. See attached draft.
> (We could simplify it a little bit if we decide to store only 1 or 0
> in all cases.)
>
> > Interestingly, if I dump and restore with:
> > $ createdb test2; pg_dump test | sql test2
> > and run the query again I get:
> > relname | attndims
> > ---------+----------
> > test | 1
> > test2 | 1
> > test3 | 1
>
> I looked at getting a better result here and decided that it didn't
> look very promising. pg_dump uses format_type() to build the type
> name to put in CREATE TABLE, and that doesn't have access to attndims.
I ran your patch with my tests and it was now consistent in a zero/non-zero
test:
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 | 2
test3 | 1
$ createdb test2; pg_dump test | sql test2
test2=>
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
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Jones | 2025-01-20 19:56:28 | Re: XMLDocument (SQL/XML X030) |
Previous Message | Tom Lane | 2025-01-20 19:35:26 | Re: [PATCH] Improve code coverage of network address functions |