Re: Minor rework of ALTER TABLE SET RelOptions code
Nikolay Shaplov <dhyan@nataraj.su>
From: Nikolay Shaplov <dhyan@nataraj.su>
To: Álvaro Herrera <alvherre@alvh.no-ip.org>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-03-18T13:38:02Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove direct handling of reloptions for toast tables
- 1548c3a30436 18.0 landed
-
ATExecSetRelOptions: Reduce scope of 'isnull' variable
- c7fc8808a91e 18.0 landed
В письме от пятница, 14 марта 2025 г. 11:35:15 MSK пользователь Álvaro Herrera написал: > > 1. `isnull` variable is actually needed in a very narrow scope, so > > it is better to keep it in that scope, not keeping it in mind in while > > dealing with the rest of the code. > > > > 2. Toast table RelOptions are never altered directly with ALTER command. > > One should do ATLER to a heap relation and use toast. reloption namespace > > to address toast's reloption. If you get `ATExecSetRelOptions` called with > > `RELKIND_TOASTVALUE` relation in the args, something is really wrong. We > > should throw asserts, errors and whistle as loud as we can. > These are two separate things, I would have suggested to post them as > two separate patches. Sounds reasonable. > And the second one lacked tests, so I added some. It never come into my mind that someone can try something like ALTER TABLE pg_toast.pg_toast_2615 SET (fillfactor = '90') and succeed. Thanks for doing that. > I have pushed both now, thanks. Thank you for commit! > I can't unfortunately promise to review the larger reloption refactoring > patch for 18. This is understandable. I will try to split this patch into parts for better readability in that time. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su