Re: attndims, typndims still not enforced, but make the value within a sane threshold

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: attndims, typndims still not enforced, but make the value within a sane threshold
Date: 2024-12-11 04:38:31
Message-ID: Z1kXR1SFtxWxOaaM@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 05, 2024 at 06:34:31PM -0500, Tom Lane wrote:
> You have a mighty optimistic view of what will happen. I predict
> that if we do step (1), exactly nothing will happen in applications,
> and step (2) will remain just as painful for them. (Assuming that
> we remember to do step (2), which is no sure thing given our track
> record for following through "in a few years".)

FWIW, my first thought after reading this paragraph is that you sound
too dramatic here, especially after looking at codesearch to note that
the PHP core code stores attndims but does not actually use it.

Now, I've looked at github and noted that there's a large number of
repositories (in the hundreds) that rely on a zero or non-zero value
for *attndims* to check if they're dealing with an array, saving in
what looks like catalog lookups.

The same lookups done for typndims offer an opposite conclusion:
there's no real code in the open that uses this value for similar
checks, most likely because domains are less used in the wild. So I
get the drama for the removal of attndims and I'd agree to keep it
around, but I also see a very good point in removing typndims.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-12-11 04:47:08 Re: Changing the state of data checksums in a running cluster
Previous Message vignesh C 2024-12-11 04:27:38 Memory leak in pg_logical_slot_{get,peek}_changes