Subject | Re: [IBO] ib_query ignores my data! |
---|---|
Author | David Trudgett |
Post date | 2001-03-22T22:50:27Z |
At 2001-03-22 13:28 -0700, "Jason Wharton" <jwharton@...> wrote:
suppose that a space character is any different from any other type of
character, whether it's in a varchar or not. Don't tread on users' data by
default! Would you gratuitously trim off zeroes because you happen to think
they're meaningless? (But we'll only do it in varchars, so that's ok! ;-))
Getting my point? :-) Trimming (by default) is a bad, bad, bad idea,
because it makes invalid assumptions about the nature of the user's data.
Databases don't impose their own view of data onto users: they just store
it and serve it up (more or less).
How many specific examples of where spaces are important need to be pointed
out?
Communications applications that demand space padding (the designer may
choose to store raw comms data in the database).
Encryption applications, which may generate spaces in the output (even at
the end!)
Arrays of flags, where a space signifies 'default' (just don't default the
last one!)
You may not do these things yourself, but people out there do, and these
people sure won't be happy about forced (or even default) trimming of spaces.
please, do the same to both CHAR and VARCHAR. There is absolutely no reason
to separate the two in this regard.
_assume_ you can change data just because you psychologically think of a
space character as different from any other character. It definitely isn't!
David Trudgett
>I am more in favor of a column type based rule than a column length basedI think that is entirely untrue. As a matter of fact, there is no reason to
>rule on the default trimming behavior. I also think that CHAR columns are
>expected to be fixed length and so trimming is mostly likely undesirable
>there. VARCHAR on the other hand is meant to be variable length so trimming
>is most likely welcomed there.
suppose that a space character is any different from any other type of
character, whether it's in a varchar or not. Don't tread on users' data by
default! Would you gratuitously trim off zeroes because you happen to think
they're meaningless? (But we'll only do it in varchars, so that's ok! ;-))
Getting my point? :-) Trimming (by default) is a bad, bad, bad idea,
because it makes invalid assumptions about the nature of the user's data.
Databases don't impose their own view of data onto users: they just store
it and serve it up (more or less).
How many specific examples of where spaces are important need to be pointed
out?
Communications applications that demand space padding (the designer may
choose to store raw comms data in the database).
Encryption applications, which may generate spaces in the output (even at
the end!)
Arrays of flags, where a space signifies 'default' (just don't default the
last one!)
You may not do these things yourself, but people out there do, and these
people sure won't be happy about forced (or even default) trimming of spaces.
>How does this sound to everyone?Not good, in case you haven't guessed by now! :-)
>Just so you know how this change will affect people... I am currently rightLeave it for V4, in my opinion (unless that's a long, long, way away). But,
>trimming both CHAR and VARCHAR column types. If you have a name column as
>CHAR after this change you are going to get padding spaces at the end of all
>your columns. Perhaps this should only be done by changing the minor version
>number to IBO v3.7 and also do it in IBO v4. Or, should I just do this in
>IBO v4 and leave 3.x totally alone here?
please, do the same to both CHAR and VARCHAR. There is absolutely no reason
to separate the two in this regard.
>Thanks for all the input on this important issue.Just remember the cardinal rule: don't mess with people's data! You can't
_assume_ you can change data just because you psychologically think of a
space character as different from any other character. It definitely isn't!
David Trudgett