From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruno Bonfils <asyd(at)asyd(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alexey Bashtanov <alexey(at)brandwatch(dot)com> |
Subject: | Re: About #13489, array dimensions and CREATE TABLE ... LIKE |
Date: | 2023-11-21 14:20:43 |
Message-ID: | ZVy8u6A3j6OxdbA0@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Nov 21, 2023 at 09:33:18AM +0100, Laurenz Albe wrote:
> On Mon, 2023-11-20 at 21:13 -0500, Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > On Mon, Nov 20, 2023 at 09:04:21PM -0500, Tom Lane wrote:
> > > > Bruce Momjian <bruce(at)momjian(dot)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.
Agreed, I see:
https://www.postgresql.org/docs/current/arrays.html
However, the current implementation ignores any supplied array
size limits, i.e., the behavior is the same as for arrays of
unspecified length.
The current implementation does not enforce the declared number
of dimensions either.
So both size limits and dimensions would be ignored.
> 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.
The CHECK constraint idea is very good.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-11-21 18:02:09 | Re: BUG #18203: Logical Replication initial sync failure |
Previous Message | Gallacher Neil | 2023-11-21 13:26:16 | ERROR: value out of range: underflow in numeric log calculation |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-11-21 14:24:22 | Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION } |
Previous Message | Jakub Wartak | 2023-11-21 14:13:09 | Re: trying again to get incremental backup |