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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Junwang Zhao <zhjwpku(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-09-23 19:30:42
Message-ID: b90d4617-04b6-47c6-86f2-b3abe0bb42cc@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-09-20 Fr 12:38 AM, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
>> On Fri, Sep 20, 2024 at 11:51:49AM +0800, Junwang Zhao wrote:
>>> Should you also bump the catalog version?
>> No need to worry about that when sending a patch because committers
>> take care of that when merging a patch into the tree. Doing that in
>> each patch submitted just creates more conflicts and work for patch
>> authors because they'd need to recolve conflicts each time a
>> catversion bump happens. And that can happen on a daily basis
>> sometimes depending on what is committed.
> Right. Sometimes the committer forgets to do that :-(, which is
> not great but it's not normally a big problem either. We've concluded
> it's better to err in that direction than impose additional work
> on patch submitters.

FWIW, I have a git pre-commit hook that helps avoid that. Essentially it
checks to see if there are changes in src/include/catalog but not in
catversion.h. That's not a 100% check, but it probably catches the vast
majority of changes that would require a catversion bump.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Tachoires 2024-09-23 19:58:14 Re: Compress ReorderBuffer spill files using LZ4
Previous Message Alexandra Wang 2024-09-23 19:22:20 Re: SQL:2023 JSON simplified accessor support