From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Bruno Bonfils <asyd(at)asyd(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, sshang(at)pivotal(dot)io, Alexey Bashtanov <alexey(at)brandwatch(dot)com> |
Subject: | Re: About #13489, array dimensions and CREATE TABLE ... LIKE |
Date: | 2023-11-21 02:04:21 |
Message-ID: | 1402391.1700532261@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2023-11-21 02:07:36 | Re: About #13489, array dimensions and CREATE TABLE ... LIKE |
Previous Message | Bruce Momjian | 2023-11-21 01:33:50 | Re: About #13489, array dimensions and CREATE TABLE ... LIKE |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2023-11-21 02:07:36 | Re: About #13489, array dimensions and CREATE TABLE ... LIKE |
Previous Message | yuansong | 2023-11-21 02:02:51 | Re:Re:Re: How to solve the problem of one backend process crashing and causing other processes to restart? |