renaming "storage parameters"

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.