From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Bruno Bonfils <asyd@asyd.net>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        sshang@pivotal.io, Alexey Bashtanov <alexey@brandwatch.com>
Subject: Re: About #13489, array dimensions and CREATE TABLE ... LIKE
In-reply-to: <ZVwI_ozT8z9MCnIZ@momjian.us>
References: <ZD+14YZ4IUue8Rhi@gendo.asyd.net> <ZPuN20z3HcBXdKow@momjian.us> <ZVwI_ozT8z9MCnIZ@momjian.us>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Mon, 20 Nov 2023 20:33:50 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1402390.1700532261.1@sss.pgh.pa.us>
Date: Mon, 20 Nov 2023 21:04:21 -0500
Message-ID: <1402391.1700532261@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1402391.1700532261%40sss.pgh.pa.us>
Precedence: bulk

Bruce Momjian <bruce@momjian.us> writes:
> I would like to apply this patch to master because I think our current
> deficiencies in this area are unacceptable.

I do not think this is a particularly good idea, because it creates
the impression in a couple of places that we track this data, when
we do not really do so to any meaningful extent.

> An alternate approach would
> be to remove pg_attribute.attndims so we don't even try to preserve 
> dimensionality.

I could get behind that, perhaps.  It looks like we're not using the
field in any meaningful way, and we could simplify TupleDescInitEntry
and perhaps some other APIs.

			regards, tom lane