Re: per-tablespace random_page_cost/seq_page_cost
| От | Robert Haas |
|---|---|
| Тема | Re: per-tablespace random_page_cost/seq_page_cost |
| Дата | |
| Msg-id | 603c8f070911022003i29a5d83q68af96920f0482e@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: per-tablespace random_page_cost/seq_page_cost (Alvaro Herrera <alvherre@commandprompt.com>) |
| Ответы |
Re: per-tablespace random_page_cost/seq_page_cost
|
| Список | pgsql-hackers |
On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Robert Haas escribió: > >> I don't see anything in this code that is very rel-specific, so I >> think it would be possible to implement spcoptions by just defining >> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of >> an unsavory feeling that I'm sure someone is going to complain about >> it... I suppose we could go through and systematically rename all >> instances of reloptions to ent(ity)options or storageoptions or >> gen(eric)options or somesuch... > > Maybe I missed part of the discussion, but do these really need to be > handled like reloptions instead of like datoptions? Perhaps the > deciding factor is that we want to parse them once and store them in a > cache, so like reloptions; the others are used once per connection and > then thrown away. This may be a stupid question, but what are datoptions? $ git grep datoptions $ > If this is the case, then I think we could just decide that their name > is reloptions due to hysterical reasons and be done with it. Yeah. It's particularly unfortunate that we call them "reloptions" in the code but "storage parameters" in the documentation. Neither is a particularly good name, and having two different ones is extra-poor. But I'm fine with leaving the names as they are and moving on, if no one objects too much. Speak now or don't complain about it after I write the patch! ...Robert
В списке pgsql-hackers по дате отправления: