While rewriting reloption.c code, I came to an idea, that all string reloptions that are used in the code are actually enum reloptions: just a fixed list of string constants, nothing more.
One string option is gist buffering, with the following validate function:
Another one is check_option for views. That also a list of two options
So the first idea, that came to me was to add a enum type, and switch the code to use it instead of string.
The second idea was, to get rid of string type at all. Because when parsing of reloptions is done, all the data is stored as a bytea binary chunk, that is copied from one memory context to another. So if there is no string data there, you can just work with it as with C structure. But if you have a string data, you should somehow put it into that data chunk, because otherwise it would not be copied from one memory context to another. This all require hacks that are not beautiful at all. And as I think should be avoided if possible. For example, this function takes a base size of reloption structure and adds some more space for each string option. I do not like this code:
So I would ask the community to consider removing string option type, if nobody really using it right now. 'cause it is kind of evil for me.
PS. If you would like to comment this post, please login from any social network that is possible to login here, or at least write your name, so I would be able to answer you...
One string option is gist buffering, with the following validate function:
gistValidateBufferingOption(char *value) { if (value == NULL || (strcmp(value, "on") != 0 && strcmp(value, "off") != 0 && strcmp(value, "auto") != 0)) { ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), errmsg("invalid value for \"buffering\" option"), errdetail("Valid values are \"on\", \"off\", and \"auto\"."))); } }
Another one is check_option for views. That also a list of two options
void validateWithCheckOption(char *value) { if (value == NULL || (pg_strcasecmp(value, "local") != 0 && pg_strcasecmp(value, "cascaded") != 0)) { ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), errmsg("invalid value for \"check_option\" option"), errdetail("Valid values are \"local\" and \"cascaded\"."))); } }
So the first idea, that came to me was to add a enum type, and switch the code to use it instead of string.
The second idea was, to get rid of string type at all. Because when parsing of reloptions is done, all the data is stored as a bytea binary chunk, that is copied from one memory context to another. So if there is no string data there, you can just work with it as with C structure. But if you have a string data, you should somehow put it into that data chunk, because otherwise it would not be copied from one memory context to another. This all require hacks that are not beautiful at all. And as I think should be avoided if possible. For example, this function takes a base size of reloption structure and adds some more space for each string option. I do not like this code:
void * allocateReloptStruct(Size base, relopt_value *options, int numoptions) { Size size = base; int i; for (i = 0; i < numoptions; i++) if (options[i].gen->type == RELOPT_TYPE_STRING) size += GET_STRING_RELOPTION_LEN(options[i]) + 1; return palloc0(size); }
So I would ask the community to consider removing string option type, if nobody really using it right now. 'cause it is kind of evil for me.
PS. If you would like to comment this post, please login from any social network that is possible to login here, or at least write your name, so I would be able to answer you...