В письме от 24 мая 2016 17:12:16 пользователь Nikolay Shaplov написал:

While working on this patch I met some difficulties that makes me to completely 
rewrite a code that is responsible for interacting reloptions.c with access 

Story start from the point that I found out that a.m. can not forbid changing 
some of it's reloptions with ALTER INDEX command. That was not necessary  
before, because all reloptions at that existed at that time can be changed on 
fly. But now for bloom index it is unacceptable, because for changing bloom's 
reloptions for existing index will lead to index malfunction.

I was thinking about adding for_alter flag argument for parseRelOptions funtion 
and pass it all the way from indexcmds.c & tablecmds.c, and add some flag in 
the definition of reloptions to mark those reloptions that should not be used 
in ALTER INDEX clause. 

This theoretically this will give us a way to throw error when user tries to 
change an reloption that should not be changed.

But unfortunately it turned out that in ATExecSetRelOptions new reloptions is 
merged with existing reloptions values using transformRelOptions, and only 
after that the result is sent for validation. 

So on the step of the validation we can not distinguish old options from a new 

I've been thinking how to work this around, but found out that there is no 
simple way. I can pass another array of flags through the whole call stack. But 
this make all thing uglier. 

I can create another function that do pre-validation for new reloptions, 
before doing final validation of the whole set. But this will make me to have  
to entities available from the a.m.: the descriptor of  reloptions and 
function for custom validation of the results (i.e. like adjustBloomOptions 
for Bloom).

But it would be not good if we dedicate two entires of a.m. to reoptions 
definition. And there can be even more... 

So I came to a conclusion: gather all the staff that defines the all the 
behavior of reloption parsing and validation into one structure, both array of 
relopt_value, custom validation function, and all the other staff.

And this structure is the only thing that a.m. gives to reloptions.c code for 
parsing and validation purposes. And that should be enough.

I hope this make code more flexible and more easy to understand.

Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to