Horton

Re: Minor rework of ALTER TABLE SET RelOptions code

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: Nikolay Shaplov <dhyan@nataraj.su>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-03-14T08:35:15Z
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 →

  1. Remove direct handling of reloptions for toast tables

  2. ATExecSetRelOptions: Reduce scope of 'isnull' variable

On 2025-Mar-07, Nikolay Shaplov wrote:

> Patch description is following:
> 
> 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.  And the second one lacked tests, so I added some.
I have pushed both now, thanks.

I can't unfortunately promise to review the larger reloption refactoring
patch for 18.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming"  (A. Stepanov)