Обсуждение: renaming "storage parameters"
Hi, Euler Taveira is arguing in an autovacuum thread that we should give "storage parameters" a different name; his argument is that "autovacuum_enabled" is not really a parameter that relates to storage. He is proposing "relation parameters". I am against the idea of renaming them, for two reasons: 1. it's a user-visible change that doesn't seem to buy a lot; 2. it's a tedious patch to write. Can I get some votes? If you think they should be renamed but to a different name than "relation parameters", please state what that is too.
On Mon, Feb 9, 2009 at 12:19 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Euler Taveira is arguing in an autovacuum thread that we should give > "storage parameters" a different name; his argument is that > "autovacuum_enabled" is not really a parameter that relates to storage. > He is proposing "relation parameters". > > I am against the idea of renaming them, for two reasons: 1. it's a > user-visible change that doesn't seem to buy a lot; 2. it's a tedious > patch to write. > > Can I get some votes? If you think they should be renamed but to a > different name than "relation parameters", please state what that is > too. -1. Even if this is a good idea in general, it's a bad idea right now, because we're trying to get 8.4 beta out the door. I also don't see that the name storage parameters is all that terrible. Surely the purpose of autovacuum is allow reuse of storage space, no? ...Robert
Alvaro Herrera <alvherre@commandprompt.com> writes: > Euler Taveira is arguing in an autovacuum thread that we should give > "storage parameters" a different name; his argument is that > "autovacuum_enabled" is not really a parameter that relates to storage. > He is proposing "relation parameters". > I am against the idea of renaming them, for two reasons: 1. it's a > user-visible change that doesn't seem to buy a lot; 2. it's a tedious > patch to write. > Can I get some votes? I agree with leaving them alone. "Storage" might not be exactly le mot juste anymore but it still gives you a good idea what they're meant for; in particular that they are targeted at implementation concerns rather than SQL-level semantics of the table. Moving to a content-free name like "relation parameter" in order to cover all possible uses doesn't seem like it helps anyone understand anything better. regards, tom lane
* Alvaro Herrera: > Euler Taveira is arguing in an autovacuum thread that we should give > "storage parameters" a different name; his argument is that > "autovacuum_enabled" is not really a parameter that relates to storage. > He is proposing "relation parameters". They also apply to indices, right? I think it's a bit odd to call those "relations" (but there's precedent inside PostgreSQL), so it's just replacing one strange terminology with another.