Euler Taveira de Oliveira wrote: > What did I already do? I refactored reloptions.c to support multiple > options. I tried to follow up the same way GUC do (of course, it is much > simpler). I'm thinking about removing (replacing?) StdRdOptions 'cause > we need a different struct to store reloptions. Suggestions? > > I'm attaching the WIP patch so you can comment on it. I want to continue > working on it but I'm afraid you already did more than I do (in this > case, let me know for not duplicating efforts).
Interesting. The main problem with this patch is that it loses the ability to pass to parseRelOptions the set of options that are valid for each context. Right now all callers use the same list comprising only fillfactor, but my guess is that once we add new options it will make sense to start differentiating. It makes no sense for indexes to have autovacuum options, for example. This is why I suggested in the email that started this thread we needed some sort of registering capability (which was thrown down). I think the main idea in your patch is fine, and better than what I was doing which was just adding every option in default_reloptions. However it needs to be adjusted somehow so that it doesn't mix all the options. Maybe we could add a "category" bitmask for which each option would be valid. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
