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'.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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=2000ms
and 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 longitude anywhere 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.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Alvaro Herrera <alvherre@commandprompt.com> writes:
> - 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?

Yeah, a HINT listing the allowed spellings of the unit would go a long
way here.

> However, preffixing with M or K does not work:

It's case-sensitive. We had that argument already, but I still think
this decision was wrong.

> - In shared_buffers, these work:
> 8MB
> 8 MB

> These don't work:
> 8M B
> 8 M B

Looking at the code, spaces before the unit are allowed, but not spaces
within or after. I agree with disallowing embedded spaces, I think,
but not allowing trailing spaces is inconsistent with our practice in
other cases (in particular, these very same variables, when written as
pure numbers...)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Am Montag, 18. Juni 2007 16:16 schrieb Tom Lane:
> It seems that time-based GUC variables can be spelled like
> ********1h******but not*********1hr
> ********1min****but not*********1m
> ********1s******but not*********1sec

The left columns are the standard units. The right columns are just randomly
made up AFAICT. If we allow that, what's someone to stop from making up
their own set?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> It's case-sensitive. We had that argument already, but I still think
> this decision was wrong.

I thought the consensus was that it should change.


--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Peter Eisentraut <peter_e@gmx.net> writes:
> Am Montag, 18. Juni 2007 16:16 schrieb Tom Lane:
>> It seems that time-based GUC variables can be spelled like
>> 1h but not 1hr
>> 1min but not 1m
>> 1s but not 1sec

> The left columns are the standard units.

Standard according to whom? In time-related contexts (eg ISO 8601)
I'd expect just "h" "m" and "s".

Since there's no likelihood that anyone would think autovacuum_naptime
is measured in meters, I think insisting that it must not be written as
"1m" is just pedantry.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Am Montag, 18. Juni 2007 19:03 schrieb Tom Lane:
> Standard according to whom?

ISO 31 a.k.a. SI

> In time-related contexts (eg ISO 8601) I'd expect just "h" "m" and "s".

ISO 8601 appears to use a slightly different syntax for writing timespans. I
would not object if anyone added support for that.

> Since there's no likelihood that anyone would think autovacuum_naptime
> is measured in meters, I think insisting that it must not be written as
> "1m" is just pedantry.

I'm pretty sure a lot of people would initially be confused why anyone would
write time in meters, let alone those that might associate it with memory
units. In my subjective view (and I acknowledge that we have all been
educated in different ways), writing "1m" for a time quantity is meaningless
and an error.

Standards exist for these things, and we have a fine tradition for choosing
standards in favor of randomness.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Am Montag, 18. Juni 2007 18:16 schrieb Alvaro Herrera:
> - We do allow preffixes in certain cases.

It would certainly be fun to have a general units system, which you could use
for configuration and data in general. But that would definitely require
that we stay strict on what we allow, or you could do no meaningful things
with this in a safe way.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"Peter Eisentraut" <peter_e@gmx.net> writes:

> I'm pretty sure a lot of people would initially be confused why anyone would
> write time in meters, let alone those that might associate it with memory
> units. In my subjective view (and I acknowledge that we have all been
> educated in different ways), writing "1m" for a time quantity is meaningless
> and an error.

That's an argument for why Postgres maybe shouldn't print times with "m" for
minutes -- though I for one would prefer it. Or why it might not be a
particularly good idea for a sysadmin to use "m" given the choice.

But to argue that Postgres should refuse "m" when presented with it you would
have to say there's a substantial chance that the user didn't mean minutes and
that there was a risk Postgres would do something bad that outweighs giving
users who do want minutes getting what they want.

Frankly, I think I see "m" as an abbreviation for minutes *more* often than
"min" anyways. I see times written as 2h30m quite frequently and then there's
precedent like this:

$ time echo

real 0m0.000s
user 0m0.000s
sys 0m0.000s


--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Mon, 2007-06-18 at 20:02 +0200, Peter Eisentraut wrote:
> Am Montag, 18. Juni 2007 19:03 schrieb Tom Lane:
> > In time-related contexts (eg ISO 8601) I'd expect just "h" "m" and "s".
>
> ISO 8601 appears to use a slightly different syntax for writing timespans. I
> would not object if anyone added support for that.
>
> > Since there's no likelihood that anyone would think autovacuum_naptime
> > is measured in meters, I think insisting that it must not be written as
> > "1m" is just pedantry.
>
> I'm pretty sure a lot of people would initially be confused why anyone would
> write time in meters,

Nobody at all is going to be confused on that point because the physical
quantity of autovacuum_naptime is clearly Time and therefore "m" would
mean minutes. Time and Distance are fairly distinct and not easily
confused, except by those with a grounding in Riemannian manifolds.

All parameters for which we can input a time unit are clearly named as
such and there would be no confusion anywhere.

You are absolutely 100% right about your units and you've clearly done
your homework, but the standard PostgreSQL should apply here is
Usability, not the absolute letter of the law as laid down in a dusty
old document. There is nothing to be gained by adherence to ISO 31 or
ISO 8601, but certainly something to be lost.

Please lets be real about this and allow the abbreviations suggested.

Your efforts to introduce units is excellent and much appreciated by
all; please don't make them harder to use than the plain numbers were.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq