Re: 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(at)commandprompt(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)gmx(dot)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(at)gmx(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Bruce Momjian" <bruce(at)momjian(dot)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(dot)l5KMLf805760(at)momjian(dot)us>, Bruce Momjian <bruce(at)momjian(dot)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

Bruce Momjian wrote:
> Simon Riggs wrote:
>> Please lets be real about this and allow the abbreviations suggested.

Agreed.

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

> Agreed. I don't see the point in following a standard few people know
> about.

It's not about a certain standard. There are so many different ways in
the world to write time units, so in a certain context a standard is
really useful to constrain the format/syntax, but...

This all was about usability of a configuration file, wasn't it? Now,
Peter, you improved that very much with this change. But do you at the
same time want to cripple the usefulness again by insisting on a certain
_syntax_, while the _semantics_ are completely clear to (guessing) 99%
of the people who will changes these settings?

To put it different, there are reasons we try to comply with the SQL
standard, not just because we feel like it. Anyone, look at the many
archive posts from Tom Lane and others, explaining why we strictly stick
to the SQL standard in some cases but allow to extend standard in others.
I just see no compelling reason to comply with a certain standard here.

Best Regards
Michael Paesold

Michael Paesold wrote:
> It's not about a certain standard. There are so many different ways in
> the world to write time units, so in a certain context a standard is
> really useful to constrain the format/syntax, but...
>
> This all was about usability of a configuration file, wasn't it? Now,
> Peter, you improved that very much with this change. But do you at the
> same time want to cripple the usefulness again by insisting on a certain
> _syntax_, while the _semantics_ are completely clear to (guessing) 99%
> of the people who will changes these settings?

FWIW, I agree entirely.

Regards, Dave

Dave Page wrote:
> Michael Paesold wrote:
>> It's not about a certain standard. There are so many different ways in
>> the world to write time units, so in a certain context a standard is
>> really useful to constrain the format/syntax, but...
>>
>> This all was about usability of a configuration file, wasn't it? Now,
>> Peter, you improved that very much with this change. But do you at the
>> same time want to cripple the usefulness again by insisting on a
>> certain _syntax_, while the _semantics_ are completely clear to
>> (guessing) 99% of the people who will changes these settings?
>
> FWIW, I agree entirely.

My 2c on this:

The way I was taught in school is that "min" is for minute and "mon" is
for month. Specifically, not "m".

I just had to download ISO 8601 and it seems irrelevant here. It talks
about using certain characters *in place* of digits, like "hh:mm", and
it talks about time periods, but that syntax is completely different,
like P1H2M, meaning 5 hour and 2 minutes.

A HINT listing the valid units is a reasonable compromise.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:

> My 2c on this:
>
> The way I was taught in school is that "min" is for minute and "mon" is for
> month. Specifically, not "m".

Sure, but nobody's saying you shouldn't be able to use "min". If you think
using "m" is wrong then by all means institute a policy at your site of using
"min" always. But the question is if someone else wants to use "m" at their
site what problems does that cause you?

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

Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
> > 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?

If everyone around here had gotten their way we'd already be in a situation
were you could write

log_rotation_age = 5m
log_rotation_size = 5m

And someone trained in the metric system would think, "What, five meters?".
So it rotates when age and size are the same or what? And the ultimate
consequence of that thinking is that the PostgreSQL developers are uneducated
dummies and clearly PostgreSQL cannot be a quality product if they can't even
get that right.

So by all means add documentation and hints.

Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway
signage, "5m" means "five miles". Even the Americans do that better. So,
no, you can't have "m" for "minutes". ;)

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

Peter Eisentraut wrote:

>Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
>
>
>>>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?
>>
>>
>
>If everyone around here had gotten their way we'd already be in a situation
>were you could write
>
>log_rotation_age = 5m
>log_rotation_size = 5m
>
>

Would it be a bad idea to always support the multi-character
abbreviations? So the min, sec, hr, day, wk, mth, yr ar all, to my
knowledge, unambiguous. As are kb, mb, gb, tb. So the above would be:
log_rotation_age = 5min
log_rotation_size = 5mb
edinburgh_distance=5mi

Brian

"Peter Eisentraut" <peter_e(at)gmx(dot)net> writes:

> Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
>> > 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?
>
> If everyone around here had gotten their way we'd already be in a situation
> were you could write
>
> log_rotation_age = 5m
> log_rotation_size = 5m
>
> And someone trained in the metric system would think, "What, five meters?".

Only if that same person had written it that way in the first place.

We're not talking about having Postgres report messages using these
abbreviations. Only accept them when they're entered by users.

> So it rotates when age and size are the same or what? And the ultimate
> consequence of that thinking is that the PostgreSQL developers are uneducated
> dummies and clearly PostgreSQL cannot be a quality product if they can't even
> get that right.

Not PostgreSQL developers, Postgres users. We already know the developers are
uneducated dummies since Tom, myself, and others have all run into this
already.

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

Peter Eisentraut wrote:

> Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway
> signage, "5m" means "five miles". Even the Americans do that better.

Yeah, but you know *exactly* what it means :-p

Regards, Dave

"Dave Page" <dpage(at)postgresql(dot)org> writes:

> Peter Eisentraut wrote:
>
>> Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway signage,
>> "5m" means "five miles". Even the Americans do that better.
>
> Yeah, but you know *exactly* what it means :-p

Well the good news is that as long as you drive at exactly 60mph you can just
take the "m" to mean minutes...

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

Gregory Stark wrote:
> "Dave Page" <dpage(at)postgresql(dot)org> writes:
>
>> Peter Eisentraut wrote:
>>
>>> Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway signage,
>>> "5m" means "five miles". Even the Americans do that better.
>> Yeah, but you know *exactly* what it means :-p
>
> Well the good news is that as long as you drive at exactly 60mph you can just
> take the "m" to mean minutes...
>

Thats a good point. Perhaps we can similarly throttle the logging rate
of the server. Just fix it at DEBUG4 or thereabouts and drop random
messages as required...

/D

Peter Eisentraut wrote:
>
> If everyone around here had gotten their way we'd already be in a situation
> were you could write
>
> log_rotation_age = 5m
> log_rotation_size = 5m
>
> And someone trained in the metric system would think, "What, five meters?".
> So it rotates when age and size are the same or what? And the ultimate
> consequence of that thinking is that the PostgreSQL developers are uneducated
> dummies and clearly PostgreSQL cannot be a quality product if they can't even
> get that right.
>
>
>

You don't seem to have any understanding that the units should be
interpreted in context. Nobody in their right mind (or perhaps only an
undeducated dummy) will think that 5m might mean five meters for
something called log_rotation_age. You might argue that it is ambiguous
between minutes and months - and for that reason at least I don't think
we should allow "m" as a unit of time. But that's a different argument.

cheers

andrew

On 6/21/07, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
> > > 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?
>
> If everyone around here had gotten their way we'd already be in a situation
> were you could write
>
> log_rotation_age = 5m
> log_rotation_size = 5m
>
> And someone trained in the metric system would think, "What, five meters?".
> So it rotates when age and size are the same or what? And the ultimate
> consequence of that thinking is that the PostgreSQL developers are uneducated
> dummies and clearly PostgreSQL cannot be a quality product if they can't even
> get that right.
>
> So by all means add documentation and hints.

Considering Postgres will never user either "meter" or "mile"
in settings, I don't consider your argument valid.

I don't see the value of having units globally unique (literally).
It's enough if they unique in the context of postgresql.conf.

Thus +1 of having additional shortcuts Tom suggested.
Also +1 for having them case-insensitive.

--
marko

Peter Eisentraut wrote:
> Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
>>> 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?
>
> If everyone around here had gotten their way we'd already be in a situation
> were you could write
>
> log_rotation_age = 5m
> log_rotation_size = 5m

There are valid reasons against 5m as mega-bytes, because here m does
not refer to a unit, it refers to a quantifier (if that is a reasonable
English word) of a unit. So it should really be 5mb.

log_rotation_age = 5m
log_rotation_size = 5mb

That is quite clear now, except, I admit, that the first could be
mistaken to mean 5 months, and perhaps this is a valid reason to not
allow 'm' for minutes. Nothing about meters here, though.

> Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway
> signage, "5m" means "five miles". Even the Americans do that better. So,
> no, you can't have "m" for "minutes". ;)

Even with the ;) here and the context, the last sentence sounds to me
quite arrogant. Most people here have tried to bring arguments and
reasoning... you put it off with irrelevant anecdotes in the wrong context.

Best Regards
Michael Paesold

Marko Kreen wrote:
> Considering Postgres will never user either "meter" or "mile"
> in settings, I don't consider your argument valid.
>
> I don't see the value of having units globally unique (literally).
> It's enough if they unique in the context of postgresql.conf.
>
> Thus +1 of having additional shortcuts Tom suggested.
> Also +1 for having them case-insensitive.

Agreed. Although I suggest perhaps to not press for "m" as minutes,
because it really is ambiguous for "months" or "minutes", esp. in a
context like "log_rotation_age".

Please lets have the unambiguous abbreviations. Please lets make it all
case-insensitive. After all this discussion, what about a straight
forward vote? Bruce, we had those before, no?

Best Regards
Michael Paesold

On 6/21/07, Michael Paesold <mpaesold(at)gmx(dot)at> wrote:
> Marko Kreen wrote:
> > Considering Postgres will never user either "meter" or "mile"
> > in settings, I don't consider your argument valid.
> >
> > I don't see the value of having units globally unique (literally).
> > It's enough if they unique in the context of postgresql.conf.
> >
> > Thus +1 of having additional shortcuts Tom suggested.
> > Also +1 for having them case-insensitive.
>
> Agreed. Although I suggest perhaps to not press for "m" as minutes,
> because it really is ambiguous for "months" or "minutes", esp. in a
> context like "log_rotation_age".

IMHO, as postgresql.conf is not a scientific article to "Nature",
we can be more relaxed about this. Currently admin-friendlyness
should top scientific precision.

As "minute" is much more needed unit that "month" it should get
shorter abbrevation. If we _do_ have unit for months for
some reason, I would even suggest removing it to make "m"
unambigious.

--
marko

Marko Kreen wrote:
> On 6/21/07, Michael Paesold <mpaesold(at)gmx(dot)at> wrote:
>> Marko Kreen wrote:
>> > Considering Postgres will never user either "meter" or "mile"
>> > in settings, I don't consider your argument valid.
>> >
>> > I don't see the value of having units globally unique (literally).
>> > It's enough if they unique in the context of postgresql.conf.
>> >
>> > Thus +1 of having additional shortcuts Tom suggested.
>> > Also +1 for having them case-insensitive.
>>
>> Agreed. Although I suggest perhaps to not press for "m" as minutes,
>> because it really is ambiguous for "months" or "minutes", esp. in a
>> context like "log_rotation_age".
>
> IMHO, as postgresql.conf is not a scientific article to "Nature",
> we can be more relaxed about this. Currently admin-friendlyness
> should top scientific precision.
>
> As "minute" is much more needed unit that "month" it should get
> shorter abbrevation. If we _do_ have unit for months for
> some reason, I would even suggest removing it to make "m"
> unambigious.

That's ok with me, too. But instead of letting this argument about "m"
get us nowhere, let's at least to the other improvements. :-)

Best Regards
Michael Paesold

Am Donnerstag, 21. Juni 2007 15:12 schrieb Andrew Dunstan:
> You don't seem to have any understanding that the units should be
> interpreted in context.

You are right. I definitely have an understanding that units must be
interpretable without context. And that clearly works for the most part.

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

Am Donnerstag, 21. Juni 2007 00:10 schrieb Gregory Stark:
> Afaict nobody has expressed a single downside to accepting other
> abbreviations.

The two downsides I can see are that it would confuse users (even if it
apparently wouldn't confuse *you*), and that there is a chance that the
configuration system would work differently from other PostgreSQL components
or parts. For example modules like earth distance or other astronomy,
physics, or geography modules might all have to create their own sets
of "clearly unambiguous" unit sets for themselves. Few or none of these
types of modules exist yet, of course. I would like to have a units-aware
data type that you can use for storing and computing with measurements, and I
would like to be able to use that same type for dealing with configuration
quantities.

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

On Thu, Jun 21, 2007 at 03:24:51PM +0200, Michael Paesold wrote:
> There are valid reasons against 5m as mega-bytes, because here m does
> not refer to a unit, it refers to a quantifier (if that is a reasonable
> English word) of a unit. So it should really be 5mb.
>
> log_rotation_age = 5m
> log_rotation_size = 5mb

Except, of course, that "5mb" would be understood by those of us who
work in metric and use both bits and bytes as 5 millibits. Which
would be an absurd value, but since Postgres had support for time
travel once, who knows what other wonders the developers have come up
with ;-) (I will note, though, that this B vs b problem really gets
up my nose, especially when I hear people who are ostensibly
designing networks talking about "gigabyte ethernet" cards. I would
_like_ such a card, I confess, but to my knowledge the standard
hasn't gotten that far yet.)

Nevertheless, I think that Tom's original suggestion was at least a
HINT, which seems perfectly reasonable to me.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie

Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
> Nevertheless, I think that Tom's original suggestion was at least a
> HINT, which seems perfectly reasonable to me.

That's the only idea in the whole thread that hasn't been objected to,
so let's just do that and have done with it. (Even if we were to agree
on loosening the accepted set of unit names, a HINT listing the accepted
names would still be needed.)

I gather Peter is travelling, so I'll take a cut at a patch. I'm
imagining that the output will look something like

ERROR: invalid value for parameter "autovacuum_naptime": "5sec"
HINT: Valid units for this parameter are "d", "h", "min", "s", "ms".

where the HINT gets appended if there's something after the integer but
it doesn't look like any of the allowed units. Objections?

regards, tom lane

On Thu, Jun 21, 2007 at 11:55:56AM -0400, Tom Lane wrote:
> where the HINT gets appended if there's something after the integer but
> it doesn't look like any of the allowed units. Objections?

Sounds like a good idea to me.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
The very definition of "news" is "something that hardly ever happens."
--Bruce Schneier

On Thursday 21 June 2007 08:34, Andrew Sullivan wrote:
> On Thu, Jun 21, 2007 at 03:24:51PM +0200, Michael Paesold wrote:
> > There are valid reasons against 5m as mega-bytes, because here m does
> > not refer to a unit, it refers to a quantifier (if that is a reasonable
> > English word) of a unit. So it should really be 5mb.
> >
> > log_rotation_age = 5m
> > log_rotation_size = 5mb
>
> Except, of course, that "5mb" would be understood by those of us who
> work in metric and use both bits and bytes as 5 millibits. Which
> would be an absurd value, but since Postgres had support for time
> travel once, who knows what other wonders the developers have come up
> with ;-) (I will note, though, that this B vs b problem really gets
> up my nose, especially when I hear people who are ostensibly
> designing networks talking about "gigabyte ethernet" cards. I would
> _like_ such a card, I confess, but to my knowledge the standard
> hasn't gotten that far yet.)

Well 10Gb ethernet d does allow for 1GB/sec so.... ;-)

>
> Nevertheless, I think that Tom's original suggestion was at least a
> HINT, which seems perfectly reasonable to me.
>
> A

Michael Paesold wrote:
> > Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway
> > signage, "5m" means "five miles". Even the Americans do that better. So,
> > no, you can't have "m" for "minutes". ;)
>
> Even with the ;) here and the context, the last sentence sounds to me
> quite arrogant. Most people here have tried to bring arguments and
> reasoning... you put it off with irrelevant anecdotes in the wrong context.

It is hard to argue with your analysis here.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Peter Eisentraut wrote:
> Am Donnerstag, 21. Juni 2007 15:12 schrieb Andrew Dunstan:
> > You don't seem to have any understanding that the units should be
> > interpreted in context.
>
> You are right. I definitely have an understanding that units must be
> interpretable without context. And that clearly works for the most part.

Consider even if we are clear that "min" is "minutes", it could be
chronological minutes or radial degree minutes, so yea, the context has
to be considered.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Michael Paesold wrote:
> Marko Kreen wrote:
> > Considering Postgres will never user either "meter" or "mile"
> > in settings, I don't consider your argument valid.
> >
> > I don't see the value of having units globally unique (literally).
> > It's enough if they unique in the context of postgresql.conf.
> >
> > Thus +1 of having additional shortcuts Tom suggested.
> > Also +1 for having them case-insensitive.
>
> Agreed. Although I suggest perhaps to not press for "m" as minutes,
> because it really is ambiguous for "months" or "minutes", esp. in a
> context like "log_rotation_age".
>
> Please lets have the unambiguous abbreviations. Please lets make it all
> case-insensitive. After all this discussion, what about a straight
> forward vote? Bruce, we had those before, no?

Right. No one dictates what goes into PostgreSQL and I think there are
clearly enough people who want improvement in this area, including
perhaps having 'm' meaning minutes and going with case insensitivity.
Please post a patch that we can discuss/review. If it is small we can
try to get it into 8.3.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Andrew Sullivan wrote:
> On Thu, Jun 21, 2007 at 03:24:51PM +0200, Michael Paesold wrote:
>> There are valid reasons against 5m as mega-bytes, because here m does
>> not refer to a unit, it refers to a quantifier (if that is a reasonable
>> English word) of a unit. So it should really be 5mb.
>>
>> log_rotation_age = 5m
>> log_rotation_size = 5mb
>
> Except, of course, that "5mb" would be understood by those of us who
> work in metric and use both bits and bytes as 5 millibits.

I at one point submitted a patch to make units case insensitive, I have
since submitting that patch decided that was a horrible idea. Why can't
we use standard units? Mb, Kb, KB, MB... (I don't know the standard unit
for minutes).

The more I see this going back and forth it seems we should just do it
right the first time and tell everyone else to read:

The fine manual
The spec(s) that define the units.

Joshua D. Drake

> Which
> would be an absurd value, but since Postgres had support for time
> travel once, who knows what other wonders the developers have come up
> with ;-) (I will note, though, that this B vs b problem really gets
> up my nose, especially when I hear people who are ostensibly
> designing networks talking about "gigabyte ethernet" cards. I would
> _like_ such a card, I confess, but to my knowledge the standard
> hasn't gotten that far yet.)
>
> Nevertheless, I think that Tom's original suggestion was at least a
> HINT, which seems perfectly reasonable to me.
>
> A
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Am Freitag, 22. Juni 2007 15:34 schrieb Bruce Momjian:
> Consider even if we are clear that "min" is "minutes", it could be
> chronological minutes or radial degree minutes, so yea, the context has
> to be considered.

The correct symbol for an arc minute is ´, so there is no context dependency.

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