Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Heikki Linnakangas [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Gregory Stark wrote: Dave Page [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC time unit spelling a bit inconsistent
On 6/21/07, Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC time unit spelling a bit inconsistent
On 6/21/07, Michael Paesold [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Marko Kreen wrote: On 6/21/07, Michael Paesold [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 | [EMAIL PROTECTED] This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Andrew Sullivan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 | [EMAIL PROTECTED] The very definition of news is something that hardly ever happens. --Bruce Schneier ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GUC time unit spelling a bit inconsistent
On Wed, Jun 20, 2007 at 5:21 PM, in message [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC time unit spelling a bit inconsistent
On Mon, 2007-06-18 at 20:02 +0200, Peter Eisentraut wrote: Am Montag, 18. Juni 2007 19:03 schrieb Tom Lane: In time-related contexts (eg ISO 8601) I'd expect just h m and s. ISO 8601 appears to use a slightly different syntax for writing timespans. I would not object if anyone added support for that. Since there's no likelihood that anyone would think autovacuum_naptime is measured in meters, I think insisting that it must not be written as 1m is just pedantry. I'm pretty sure a lot of people would initially be confused why anyone would write time in meters, Nobody at all is going to be confused on that point because the physical quantity of autovacuum_naptime is clearly Time and therefore m would mean minutes. Time and Distance are fairly distinct and not easily confused, except by those with a grounding in Riemannian manifolds. All parameters for which we can input a time unit are clearly named as such and there would be no confusion anywhere. You are absolutely 100% right about your units and you've clearly done your homework, but the standard PostgreSQL should apply here is Usability, not the absolute letter of the law as laid down in a dusty old document. There is nothing to be gained by adherence to ISO 31 or ISO 8601, but certainly something to be lost. Please lets be real about this and allow the abbreviations suggested. Your efforts to introduce units is excellent and much appreciated by all; please don't make them harder to use than the plain numbers were. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Tom Lane wrote: It seems that time-based GUC variables can be spelled like 1h but not 1hr 1minbut 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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Alvaro Herrera [EMAIL PROTECTED] writes: - I was bitten by this too, not long ago, and took me a while to understand why. Should we at least log a HINT or something? Yeah, a HINT listing the allowed spellings of the unit would go a long way here. However, preffixing with M or K does not work: It's case-sensitive. We had that argument already, but I still think this decision was wrong. - In shared_buffers, these work: 8MB 8 MB These don't work: 8M B 8 M B Looking at the code, spaces before the unit are allowed, but not spaces within or after. I agree with disallowing embedded spaces, I think, but not allowing trailing spaces is inconsistent with our practice in other cases (in particular, these very same variables, when written as pure numbers...) regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GUC time unit spelling a bit inconsistent
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 1minbut not 1m 1s but not 1sec The left columns are the standard units. The right columns are just randomly made up AFAICT. If we allow that, what's someone to stop from making up their own set? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Peter Eisentraut [EMAIL PROTECTED] 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 1minbut not 1m 1s but not 1sec The left columns are the standard units. Standard according to whom? In time-related contexts (eg ISO 8601) I'd expect just h m and s. Since there's no likelihood that anyone would think autovacuum_naptime is measured in meters, I think insisting that it must not be written as 1m is just pedantry. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Am Montag, 18. Juni 2007 18:16 schrieb Alvaro Herrera: - We do allow preffixes in certain cases. It would certainly be fun to have a general units system, which you could use for configuration and data in general. But that would definitely require that we stay strict on what we allow, or you could do no meaningful things with this in a safe way. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Peter Eisentraut [EMAIL PROTECTED] 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 real0m0.000s user0m0.000s sys 0m0.000s -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Am Montag, 18. Juni 2007 19:03 schrieb Tom Lane: Standard according to whom? ISO 31 a.k.a. SI In time-related contexts (eg ISO 8601) I'd expect just h m and s. ISO 8601 appears to use a slightly different syntax for writing timespans. I would not object if anyone added support for that. Since there's no likelihood that anyone would think autovacuum_naptime is measured in meters, I think insisting that it must not be written as 1m is just pedantry. I'm pretty sure a lot of people would initially be confused why anyone would write time in meters, let alone those that might associate it with memory units. In my subjective view (and I acknowledge that we have all been educated in different ways), writing 1m for a time quantity is meaningless and an error. Standards exist for these things, and we have a fine tradition for choosing standards in favor of randomness. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC time unit spelling a bit inconsistent
Tom Lane [EMAIL PROTECTED] writes: It's case-sensitive. We had that argument already, but I still think this decision was wrong. I thought the consensus was that it should change. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
