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.