Re: GUC time unit spelling a bit inconsistent

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: GUC time unit spelling a bit inconsistent
Дата
Msg-id 20070618161656.GC13688@alvh.no-ip.org
обсуждение исходный текст
Ответ на GUC time unit spelling a bit inconsistent  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: GUC time unit spelling a bit inconsistent  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: GUC time unit spelling a bit inconsistent  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Tom Lane wrote:
> It seems that time-based GUC variables can be spelled like
>     1h    but not        1hr
>     1min    but not        1m
>     1s    but not        1sec
> This is inconsistent and confusing.  I don't object to the ones on the
> left as being the standard spellings for printout, but if we're not
> going to have a simple uniform rule like "shortest possible
> abbreviation" then we ought to accept plausible alternatives on input.
> 
> I got burnt by this just now because I looked at the autovacuum_naptime
> setting in postgresql.conf, which is shown as '1min', and figured I
> could change it to '5sec'.

Some random observations:

- I was bitten by this too, not long ago, and took me a while to understand why.  Should we at least log a HINT or
something?

- We do allow preffixes in certain cases.  For example I can specify a naptime in milliseconds: $ postmaster -c
autovacuum_naptime=2000msand it shows up as "2s" in SHOW.
 
 However, preffixing with M or K does not work: $ postmaster -c autovacuum_naptime=2Ms FATAL:  parameter
"autovacuum_naptime"requires an integer value $ postmaster -c autovacuum_naptime=2Ks FATAL:  parameter
"autovacuum_naptime"requires an integer value
 
 "millihours" doesn't seem to work either.

- In shared_buffers, these work: 8MB 8 MB
 These don't work: 8M B 8 M B 8mB 8m 8M
 I think this means we could safely use "m" as an abbreviation for "minutes", where it is not preffixed by anything
else(so "mm" would not mean milliminutes, nor millimeters).  It is not confused with meters because we don't use
longitudeanywhere in our configuration settings and are not likely to start doing so in the foreseeable future.
 

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Reducing NUMERIC size for 8.3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: GUC time unit spelling a bit inconsistent