On Mon, 2023-11-20 at 21:13 -0500, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Mon, Nov 20, 2023 at 09:04:21PM -0500, Tom Lane wrote: > > > Bruce Momjian <br...@momjian.us> writes: > > > > 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. > > > So should I work on that patch or do you want to try? I think we should > > do something. > > Let's wait for some other opinions, first ...
Looking at the code, I get the impression that we wouldn't lose anything without "pg_attribute.attndims", so +1 for removing it. This would call for some documentation. We should remove most of the documentation about the non-existing difference between declaring a column "integer[]", "integer[][]" or "integer[3][3]" and just describe the first variant in detail, perhaps mentioning that the other notations are accepted for backward compatibility. I also think that it would be helpful to emphasize that while dimensionality does not matter to a column definition, it matters for individual array values. Perhaps it would make sense to recommend a check constraint if one wants to make sure that an array column should contain only a certain kind of array. Yours, Laurenz Albe
