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
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 |