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 writes:
> > > On Mon, Nov 20, 2023 at 09:04:21PM -0500, Tom Lane wrote:
> > > > Bruce Momjian writes:
> > > > > An alternate approach would
> > > > > be to remove p
On Mon, 2023-11-20 at 21:13 -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Nov 20, 2023 at 09:04:21PM -0500, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > An alternate approach would
> > > > be to remove pg_attribute.attndims so we don't even try to preserve
> > > > dimensional
Bruce Momjian writes:
> On Mon, Nov 20, 2023 at 09:04:21PM -0500, Tom Lane wrote:
>> Bruce Momjian 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 us
On Mon, Nov 20, 2023 at 09:04:21PM -0500, Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 s
On Fri, Sep 8, 2023 at 05:10:51PM -0400, Bruce Momjian wrote:
> I knew we only considered the array dimension sizes to be documentation
> _in_ the query, but I thought we at least properly displayed the number
> of dimensions specified at creation when we described the table in psql,
> but it seem
