Thread: GUC time unit spelling a bit inconsistent
It seems that time-based GUC variables can be spelled like1h but not 1hr1min but not 1m1s 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=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.
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 lastme 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@enterprisedb.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:<br /><blockquote cite="mid200706211438.55075.peter_e@gmx.net" type="cite"><pre wrap="">Am Donnerstag,21. Juni 2007 00:38 schrieb Gregory Stark: </pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">Ithink people are worried that an 'm' in one column might mean something different than an 'm' in another column, and perhaps that is confusing. </pre></blockquote><pre wrap="">To whom? theperson writing it? </pre></blockquote><pre wrap=""> 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 </pre></blockquote><br /> 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 theabove would be:<br /> log_rotation_age = 5min<br /> log_rotation_size = 5mb<br /> edinburgh_distance=5mi<br /><br /> Brian<br/>
"Peter Eisentraut" <peter_e@gmx.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@postgresql.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@postgresql.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@gmx.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@gmx.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@gmx.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@crankycanuck.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@crankycanuck.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@crankycanuck.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@momjian.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@momjian.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@momjian.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/