В письме от 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 methods. 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 one. 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: http://www.postgresql.org/mailpref/pgsql-hackers
