Yes, and I can't think of a single reason why we'd let people
specify
anything in millibytes, or kilobits.
How about a configuration option related to connection throughput,
which is
typically measured in bits?
We'd use kbit. I don't see us using kb in that case (or was it kB
:-).
You just proved the case for why the units shouldn't be case sensitive:
On Dec 30, 2006, at 6:36 PM, Andrew Hammond wrote:
I agree. But perhaps the solution instead of failing is to throw a
warning to the effect of Not to be pedantic, but you said mb and
millibits as a unit doesn't make sense
Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
Yes, and I can't think of a single reason why we'd let people specify
anything in millibytes, or kilobits.
How about a configuration option related to connection throughput, which is
typically measured in bits?
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
Yes, and I can't think of a single reason why we'd let people specify
anything in millibytes, or kilobits.
How about a configuration option related to connection throughput, which is
TL == Tom Lane [EMAIL PROTECTED] writes:
TL Personally I don't find the argument about someday we might want
TL to support measurements in millibits to be convincing at all, and
TL certainly it seems weaker than the argument that units should be
TL case insensitive because everything else in
Benny Amorsen [EMAIL PROTECTED] writes:
TL == Tom Lane [EMAIL PROTECTED] writes:
TL Personally I don't find the argument about someday we might want
TL to support measurements in millibits to be convincing at all, and
TL certainly it seems weaker than the argument that units should be
TL case
Benny Amorsen wrote:
TL == Tom Lane [EMAIL PROTECTED] writes:
TL Anyone against making it case-insensitive, speak now or hold your
TL peace.
SI-units are inherently case-sensitive. The obvious example is that
now you will allow people to specify an amount in millibytes, while
interpreting
Andrew Hammond [EMAIL PROTECTED] writes:
I agree. But perhaps the solution instead of failing is to throw a
warning to the effect of Not to be pedantic, but you said mb and
millibits as a unit doesn't make sense in this context. Assuming you
meant MB (MegaBits). and then start up.
Generally
JCN == Jim C Nasby [EMAIL PROTECTED] writes:
JCN Truth is, I bet many (if not most) DBAs barely know that case
JCN matters in the units.
Sounds like the school system needs fixing, then.
/Benny
---(end of broadcast)---
TIP 7: You can help
Benny Amorsen wrote:
JCN == Jim C Nasby [EMAIL PROTECTED] writes:
JCN Truth is, I bet many (if not most) DBAs barely know that case
JCN matters in the units.
Sounds like the school system needs fixing, then.
Sure, but it probably shows a lot more prominently in other areas than
in unit
On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
TL == Tom Lane [EMAIL PROTECTED] writes:
TL Anyone against making it case-insensitive, speak now or hold your
TL peace.
SI-units are inherently case-sensitive. The obvious example is that
now you will allow people to specify
TL == Tom Lane [EMAIL PROTECTED] writes:
TL Anyone against making it case-insensitive, speak now or hold your
TL peace.
SI-units are inherently case-sensitive. The obvious example is that
now you will allow people to specify an amount in millibytes, while
interpreting it in megabytes.
You are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
TL == Tom Lane [EMAIL PROTECTED] writes:
TL Anyone against making it case-insensitive, speak now or hold your
TL peace.
SI-units are inherently case-sensitive [...]
As a
On Tue, 2006-12-19 at 22:06 -0800, Steve Atkins wrote:
On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:
On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:
I think we should just accept the strings case-insensitively, too.
While acknowledging Peter's pedantically-correct points, I say +1
Joshua D. Drake [EMAIL PROTECTED] writes:
On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:
I think we should just accept the strings case-insensitively, too.
Where we at on this?
Anyone against making it case-insensitive, speak now or hold your peace.
regards, tom lane
Tom Lane wrote:
(Hmm, I wonder what Tom Dunstan's enum patch does about case
sensitivity...)
Currently enum labels are case sensitive. I was a bit ambivalent about
it... case insensitivity can lead to less surprises in some cases, but
many programming languages that have enums are case
On Tue, Dec 19, 2006 at 10:12:34PM +, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive
Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
I suppose we should think about mysql refugees at some point, though. I
wonder what they do. The documentation is silent on the matter (and all
their examples are in lower case). Mysql is generally case insensitive,
right?
Maybe you
Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
I suppose we should think about mysql refugees at some point, though. I
wonder what they do. The documentation is silent on the matter (and all
their examples are in lower case). Mysql is generally case
On Mon, Dec 18, 2006 at 08:56:22PM -0800, Joshua D. Drake wrote:
On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make everything case-insensitive -- but
case-preserving! -- on Windows only?
--
Peter Eisentraut
On Tue, Dec 19, 2006 at 10:01:05AM +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make everything
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make everything case-insensitive --
On Tue, 2006-12-19 at 13:32 -0800, Joshua D. Drake wrote:
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of
Joshua D. Drake wrote:
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make
On Tue, 2006-12-19 at 16:47 -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with
Joshua D. Drake wrote:
+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #
Well, if you add that, you should also list all the other valid units.
But it's quite redundant, because nearly all the
On Tue, 2006-12-19 at 22:59 +0100, Peter Eisentraut wrote:
Joshua D. Drake wrote:
+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #
Well, if you add that, you should also list all the other valid
Peter Eisentraut wrote:
Joshua D. Drake wrote:
+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #
Well, if you add that, you should also list all the other valid units.
But it's quite redundant,
Bruce Momjian wrote:
The only value to being case-sensitive in this area is to allow
upper/lower case with different meanings, but I don't see us using
that, so why do we bother caring about the case?
Because the units are what they are.
In broader terms, we may one day want to have other
In my mind, this is pretty silly. There is no reputable precedent
anywhere for variant capitalization in unit names.
I am not suggestion variant capitalization. I am suggestion a simple
document patch to help eliminate what may not be obvious.
Good lord... *suggesting*
Joshua D. Drake
Tom Lane [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive manner, and the forces of pedantry won the first
round. Shall we
Magnus Hagander wrote:
In most cases, I just assume they would just assume
they can't use units on it because the default value in the file
doesn't have units.
But the default value *does* have units.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
Magnus Hagander wrote:
In most cases, I just assume they would just assume
they can't use units on it because the default value in the file
doesn't have units.
But the default value *does* have units.
It does? Didn't in my file. I must've overwritten it with a
On Tue, 2006-12-19 at 23:39 +0100, Magnus Hagander wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
In most cases, I just assume they would just assume
they can't use units on it because the default value in the file
doesn't have units.
But the default value *does* have units.
Joshua D. Drake wrote:
I am not suggestion variant capitalization. I am suggestion a simple
document patch to help eliminate what may not be obvious.
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of invalid integer. I'd
Kenneth Marshall [EMAIL PROTECTED] writes:
My one comment is that a little 'b' is used to indicate bits normally
and a capital 'B' is used to indicate bytes. So
kb = '1024 bits'
kB = '1024 bytes'
I do think that whether or not the k/m/g is upper case or lower case
is
Gregory Stark wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
My one comment is that a little 'b' is used to indicate bits normally
and a capital 'B' is used to indicate bytes. So
kb = '1024 bits'
kB = '1024 bytes'
I do think that whether or not the k/m/g is upper
Peter Eisentraut [EMAIL PROTECTED] writes:
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of invalid integer. I'd
imagine invalid memory unit: TB would be less confusing.
+1 on that, but I think we should just accept the
On Tue, 2006-12-19 at 19:16 -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of invalid integer. I'd
imagine invalid memory unit: TB would be less confusing.
Tom Lane wrote:
Nor do I believe that we'd ever accept a future patch that made
the distinction between kb and kB significant --- if you think
people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future functionality like a units-aware
data type,
Joshua D. Drake wrote:
I compiled and installed, ran an initdb with 32mb (versus 32MB) and
it seems to work correctly with a show shared_buffers;
Did it actually allocate 32 millibits of shared buffers?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Tom Lane wrote:
+1 on that, but I think we should just accept the strings
case-insensitively, too.
I think if we'd allow this to spread, documentation, example files and
other material would use it inconsistently, and even more people would
be confused and it would make us look silly.
It's
On Wed, 2006-12-20 at 02:19 +0100, Peter Eisentraut wrote:
Joshua D. Drake wrote:
I compiled and installed, ran an initdb with 32mb (versus 32MB) and
it seems to work correctly with a show shared_buffers;
Did it actually allocate 32 millibits of shared buffers?
Funny :)
Joshua D. Drake
Hello,
Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
Thanks to AndrewS for pointing out that I shouldn't use strcasecp().
That should be AndrewD :)
J
I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
seems to work correctly with a show
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Nor do I believe that we'd ever accept a future patch that made
the distinction between kb and kB significant --- if you think
people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future
Peter Eisentraut wrote:
Tom Lane wrote:
Nor do I believe that we'd ever accept a future patch that made
the distinction between kb and kB significant --- if you think
people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future functionality like a
On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:
I think we should just accept the strings case-insensitively, too.
While acknowledging Peter's pedantically-correct points, I say +1 for
ease of use.
--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation
On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:
On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:
I think we should just accept the strings case-insensitively, too.
While acknowledging Peter's pedantically-correct points, I say +1 for
ease of use.
+1. I spend some time walking people
Is there any special reason why I can't use Mb and Gb and such for
effective_cache_size, the way I can for say shared_buffers?
//Magnus
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
Magnus Hagander wrote:
Is there any special reason why I can't use Mb and Gb and such
for effective_cache_size, the way I can for say shared_buffers?
You can't use Mb or Gb for shared_buffers either, because those are
not accepted units.
--
Peter Eisentraut
On Mon, 2006-12-18 at 22:08 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is there any special reason why I can't use Mb and Gb and such
for effective_cache_size, the way I can for say shared_buffers?
You can't use Mb or Gb for shared_buffers either, because those are
not
Peter Eisentraut wrote:
Magnus Hagander wrote:
Is there any special reason why I can't use Mb and Gb and such
for effective_cache_size, the way I can for say shared_buffers?
You can't use Mb or Gb for shared_buffers either, because those are
not accepted units.
Oh, you mean MB vs Mb.
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive manner, and the forces of pedantry won the first
round. Shall we reopen that argument?
On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive manner, and the forces of pedantry won the first
round.
55 matches
Mail list logo
