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 i
> > 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
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
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
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 sho
> "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 everyth
"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.
> G
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, wh
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 area
> "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 ca
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 p
-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 [...
> "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.
"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,
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 point
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 insensit
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
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
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 sensi
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 th
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
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
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 imagin
> 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
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. D
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
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:
> 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
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
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
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
"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
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
im
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
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 wi
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/
---
"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. Sh
> > 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.
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 u
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 r
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
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 para
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 w
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 abou
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,
> >
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-insens
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 case
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 Eisentrau
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 string
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
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?
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 m
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
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
http://developer.postgres
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
h
55 matches
Mail list logo
