GUC time unit spelling a bit inconsistent
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
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.
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
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/
"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
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
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/
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/
"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
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
Simon Riggs wrote:
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.
Agreed. I don't see the point in following a standard few people know
about.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Agreed. I don't see the point in following a standard few people know
about.
Few people in the US and UK you mean, right? Everybody else stopped
measuring in king's feet and thumbs a long time ago.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Am Mittwoch, 20. Juni 2007 05:54 schrieb Bruce Momjian:
Agreed. �I don't see the point in following a standard few people know
about.
Yes, let's drop SQL as well.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
Am Mittwoch, 20. Juni 2007 05:54 schrieb Bruce Momjian:
Agreed. ?I don't see the point in following a standard few people know
about.Yes, let's drop SQL as well.
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.
If we're not going to make the units-parsing any more friendly, for
gosh sakes let's at least make it give a HINT about what it will accept.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.If we're not going to make the units-parsing any more friendly, for
gosh sakes let's at least make it give a HINT about what it will accept.
yeah a proper HINT seem like a very reasonable compromise ...
Stefan
"Bruce Momjian" <bruce@momjian.us> writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.
Could you expand on your logic here? And why you disagree with my argument
that which abbreviations are correct is irrelevant in deciding whether we
should accept other abbreviations.
Afaict nobody has expressed a single downside to accepting other
abbreviations.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote:
"Bruce Momjian" <bruce@momjian.us> writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.Could you expand on your logic here? And why you disagree with my argument
that which abbreviations are correct is irrelevant in deciding whether we
should accept other abbreviations.
I suppose the idea is that we don't want to be sloppy about accepting
just anything in postgresql.conf. I think people are worried that an
'm' in one column might mean something different than an 'm' in another
column, and perhaps that is confusing.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
"Bruce Momjian" <bruce@momjian.us> writes:
I suppose the idea is that we don't want to be sloppy about accepting
just anything in postgresql.conf.
becuase?
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is confusing.
To whom? the person writing it?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
On Wed, Jun 20, 2007 at 5:21 PM, in message
<200706202221.l5KMLf805760@momjian.us>, Bruce Momjian <bruce@momjian.us> wrote:
Gregory Stark wrote:
Could you expand on your logic here? And why you disagree with my argument
that which abbreviations are correct is irrelevant in deciding whether we
should accept other abbreviations.I suppose the idea is that we don't want to be sloppy about accepting
just anything in postgresql.conf. I think people are worried that an
'm' in one column might mean something different than an 'm' in another
column, and perhaps that is confusing.
If we want precision and standards, I would personally find ISO 8601 4.4.3.2 less confusing than the current implementation. (You could say 'PT2M30S' or 'PT2,5M' or 'PT2.5M' to specify a 2 minute and 30 second interval.) That said, I'd be OK with a HINT that listed valid syntax. I've wasted enough time looking up the supported abbreviations to last me a while.
-Kevin
