The Daily WTF: Curious Perversions in Information Technology

nerd4sale · 2014-06-23 Reply Admin

Those fristy Siberian winters...

2014-06-23 Reply Admin

how would SQL injection work in this case?

"\";- drop Table \"Subscription\\""

so improved security

2014-06-23 Reply Admin

Better than this:

TheCPUWizard · 2014-06-23 Reply Admin

Can I quote you on that?

2014-06-23 Reply Admin

TRWTF is Postgres

2014-06-23 Reply Admin

Fitfh

2014-06-23 Reply Admin

Dave:
Fitfh

I'm sorry Dave, I'm afraid you can't do that.

2014-06-23 Reply Admin

TRWTF:

Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)

This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

2014-06-23 Reply Admin

ALLOWING CASE IS OVERRATED

2014-06-23 Reply Admin

'Single quotes would have been "way" easier.'

2014-06-23 Reply Admin

Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

Most stupid invention in modern programming languages is case sensitive variables. A programmer would never find his way to "Main Street" as the sign says "MAIN STREET"

PedanticCurmudgeon · 2014-06-23 Reply Admin

Vitaly replied that the Barracuda database had been converted from MySQL to Postgres, and, not wanting to change all the table names from uppercase, they'd simply quoted every identifier on import.

Siberia is historically a place where troublemakers were sent, so where do you send troublemakers like Vitaly who are already in Siberia?

Nook Schreier · 2014-06-23 Reply Admin

PedanticCurmudgeon:
Siberia is historically a place where troublemakers were sent, so where do you send troublemakers like Vitaly who are already in Siberia?

Detroit.

PedanticCurmudgeon · 2014-06-23 Reply Admin

Nook Schreier:
PedanticCurmudgeon:
Siberia is historically a place where troublemakers were sent, so where do you send troublemakers like Vitaly who are already in Siberia?

Detroit.

I used to live there. Can confirm.

2014-06-23 Reply Admin

Something tells me that The Database Architect probably insisted on preserving the case of all the identifiers.

(And, as usual, the cost of the change, in terms of its impact on all the code that used the database was "irrelevant trivia" -- to The Database Architect.)

2014-06-23 Reply Admin

Why did he have to add the quotes instead of just writing it with an upper-case "S"? If the quotes in psql make the names case-sensitive, it should be sufficient to respect the case, right?

2014-06-23 Reply Admin

When the app I was creating as a sole-dev required a MYSQL-to-Postgres migration, I faced that. Quickly got rid of my old job habit of using uppercase identifiers.

It was for the best too... it looked cleaner.

2014-06-23 Reply Admin

Hasse de great:
Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

Most stupid invention in modern programming languages is case sensitive variables. A programmer would never find his way to "Main Street" as the sign says "MAIN STREET"

That's not a case sensitive variable you bloody wonk, it's case sensitive DATA.

2014-06-23 Reply Admin

Funnyguy:
TRWTF is Postgres

Why is Postgres TRWTF? You don't like a feature rich free RDBMS?

2014-06-23 Reply Admin

huppenzuppen:
Why did he have to add the quotes instead of just writing it with an upper-case "S"? If the quotes in psql make the names case-sensitive, it should be sufficient to respect the case, right?

Should be, but apparently isn't...

psql=>select ID, template from "Subscription";
ERROR: column "ID" does not exist

2014-06-23 Reply Admin

Harrow:
Hasse de great:
Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

Most stupid invention in modern programming languages is case sensitive variables. A programmer would never find his way to "Main Street" as the sign says "MAIN STREET"
That's not a case sensitive variable you bloody wonk, it's case sensitive DATA.

Street NAMES and variable NAMES are both human-friendly labels. Hence why they're both called "names". That's what names are supposed to be: human-friendly labels.

2014-06-23 Reply Admin

Hasse de great:
Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

Most stupid invention in modern programming languages is case sensitive variables. A programmer would never find his way to "Main Street" as the sign says "MAIN STREET"

I'd have to disagree.

While it's an inconvenience, I wouldn't want to allow programmers to code like this.

var MAinsTReet = ... maINSreET = ...

And besides if you use camel case.

upperSon upPerson

are two different things

2014-06-23 Reply Admin

Valued Service:
Hasse de great:
Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

Most stupid invention in modern programming languages is case sensitive variables. A programmer would never find his way to "Main Street" as the sign says "MAIN STREET"

I'd have to disagree.

While it's an inconvenience, I wouldn't want to allow programmers to code like this.

var MAinsTReet = ... maINSreET = ...

And besides if you use camel case.

upperSon upPerson

are two different things

IDE should convert everything to match the case of the variable definition, and flag it immediately if you define two variables with the same name. Not a problem.

2014-06-23 Reply Admin

PedanticCurmudgeon:
Siberia is historically a place where troublemakers were sent, so where do you send troublemakers like Vitaly who are already in Siberia?

The White House.

ba-dum!

pjt33 · 2014-06-23 Reply Admin

Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case.

Thank you. I was wondering why Nathan had to quote ID, even though it was already in caps. Mods, any chance of a blue highlight for Gill's comment?

2014-06-23 Reply Admin

And now his comparison fails due to different ordering of the returned data?

2014-06-23 Reply Admin

anonymous:
IDE should convert everything to match the case of the variable definition, and flag it immediately if you define two variables with the same name. Not a problem.

It does both those things already, and supports case sensitivity.

What do you do if you have two variables? upPerson upperSon

If both names make perfect sense, now you have to choose a different name for no apparent reason. If these are perfectly sufficient names, you now have to complicate one of the names. The human eye will read these as two different names easily. They won't be confused.

2014-06-23 Reply Admin

Valued Service:
And besides if you use camel case.
upperSon upPerson

are two different things

  if (gotHere ())
goThere ();

cellocgw · 2014-06-23 Reply Admin

nerd4sale:
Those fristy Siberian winters...

Frist quote of "frist" post.

chubertdev · 2014-06-23 Reply Admin

Valued Service:
anonymous:
IDE should convert everything to match the case of the variable definition, and flag it immediately if you define two variables with the same name. Not a problem.

It does both those things already, and supports case sensitivity.

What do you do if you have two variables? upPerson upperSon

If both names make perfect sense, now you have to choose a different name for no apparent reason. If these are perfectly sufficient names, you now have to complicate one of the names. The human eye will read these as two different names easily. They won't be confused.

If you want variables named so similarly, you deserve to get whacked with a cluebat.

Zemm · 2014-06-23 Reply Admin

So using single quotes in the shell like

psql -Upsql -t -c 'select "ID", "Template" from "Subscription";' > file

was too good for him?

2014-06-23 Reply Admin

"upPerson, upperSon" -> give up on camel case, the sooner the better -> up_person, upper_son.

whyWouldWeThinkItsAGoodIdeaToJamWordsTogether

2014-06-23 Reply Admin

Is it shameful that I've become such a cynic from visiting this site that I doubt the story took place in Siberia?

2014-06-23 Reply Admin

John:
"upPerson, upperSon" -> give up on camel case, the sooner the better -> up_person, upper_son.
whyWouldWeThinkItsAGoodIdeaToJamWordsTogether

Because separating words was a measure taken to make reading available to the public. Ancient Hebrew didn't separate words, and they didn't have vowels either.

youcanreadthisjustfineifyoutried

wedonotevenneeduppercasetoreadthisorpunctuationforthatmatter

itjusttakesslightlylongertoread

2014-06-23 Reply Admin

foo AKA fooo:
Valued Service:
And besides if you use camel case.
upperSon upPerson

are two different things
  if (gotHere ())
goThere ();

 var penIslandUrl = "www.penisland.com";

2014-06-23 Reply Admin

quux:
foo AKA fooo:
Valued Service:
And besides if you use camel case.
upperSon upPerson

are two different things
  if (gotHere ())
goThere ();
 var penIslandUrl = "www.penisland.com"; 

expertsexchange

It's a real site. No, it's not about surgery.

When naming your site/company, it's a good idea to convert to lowercase and merge the words, just to be sure you are ok with the result.

Email, web address, and so on, all require it.

2014-06-23 Reply Admin

Valued Service:
Because separating words was a measure taken to make reading available to the public. Ancient Hebrew didn't separate words, and they didn't have vowels either.
youcanreadthisjustfineifyoutried

wedonotevenneeduppercasetoreadthisorpunctuationforthatmatter

itjusttakesslightlylongertoread

hw mprtnt r vwls thn?

wthtspcsthrprbblymprtnt

2014-06-23 Reply Admin

Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

Or you could just always make everything case-insensitive, and then there would be no issue.

The problem is when it's sometimes one and sometimes the other.

2014-06-23 Reply Admin

Valued Service:
anonymous:
IDE should convert everything to match the case of the variable definition, and flag it immediately if you define two variables with the same name. Not a problem.

It does both those things already, and supports case sensitivity.

What do you do if you have two variables? upPerson upperSon

If both names make perfect sense, now you have to choose a different name for no apparent reason. If these are perfectly sufficient names, you now have to complicate one of the names. The human eye will read these as two different names easily. They won't be confused.

No, now you have to use a different name for a very good reason: Because the two names look the same.

Maybe the human eyes that you are familiar with are different from those of any human being I have ever known, but most people I know see "Main" and "main" as the same word. When I'm working in case-sensitive languages, I regularly stumble over whether a function is called "getFoobar" or "GetFoobar".

I've had to work on programs where the programmer thought it was clever to have variable names that differed only in that he left out a letter in one, like "freight" and "freigt" and "amount" and "amout" (both real examples). Such programs can be very tricky to read. If someone really had "upperSon" and "upPerson" as two different variables, I think I'd strangle him.

2014-06-23 Reply Admin

Valued Service:
John:
"upPerson, upperSon" -> give up on camel case, the sooner the better -> up_person, upper_son.
whyWouldWeThinkItsAGoodIdeaToJamWordsTogether

Because separating words was a measure taken to make reading available to the public. Ancient Hebrew didn't separate words, and they didn't have vowels either.

youcanreadthisjustfineifyoutried

wedonotevenneeduppercasetoreadthisorpunctuationforthatmatter

itjusttakesslightlylongertoread

Now I understand how ancient Israel was conquered. A soldier at the front sent back the dire warning, "The Babylonians are now here!", but writing it without spaces, it was interpreted as "The Babylonians are nowhere."

2014-06-23 Reply Admin

While your eye is easily discerning those two "personable" variable names, how about these two?

model mode1

They ARE spelled differently. It's quite conceivable that the could be found in the same routine.

Now picture yourself sitting in front of a computer screen for hours...

Mayhaps we need that evil cameLcase and a compiler that's case sensitive. Or we could just pick better variable names.

2014-06-23 Reply Admin

Why not use "[]" brackets?

2014-06-23 Reply Admin

foo AKA fooo:
Valued Service:
And besides if you use camel case.
upperSon upPerson

are two different things
  if (gotHere ())
goThere ();

Camel_case_is_overrated._Underscores_are_the_way_to_go()

2014-06-23 Reply Admin

Bob:
While your eye is easily discerning those two "personable" variable names, how about these two?
model mode1

They ARE spelled differently. It's quite conceivable that the could be found in the same routine.

Now picture yourself sitting in front of a computer screen for hours...

Mayhaps we need that evil cameLcase and a compiler that's case sensitive. Or we could just pick better variable names.

There are only two hard things in computer science: Cache invalidation, naming things and off-by-one errors.

2014-06-23 Reply Admin

Hasse de great:
Bob:
While your eye is easily discerning those two "personable" variable names, how about these two?
model mode1

They ARE spelled differently. It's quite conceivable that the could be found in the same routine.

Now picture yourself sitting in front of a computer screen for hours...

Mayhaps we need that evil cameLcase and a compiler that's case sensitive. Or we could just pick better variable names.
There are only two hard things in computer science: Cache invalidation, naming things and off-by-one errors.

Touche'

Gene Wirchenko · 2014-06-23 Reply Admin

Valued Service:
Because separating words was a measure taken to make reading available to the public. Ancient Hebrew didn't separate words, and they didn't have vowels either.
youcanreadthisjustfineifyoutried

wedonotevenneeduppercasetoreadthisorpunctuationforthatmatter

itjusttakesslightlylongertoread

Many times longer. I can read space-delimited words very quickly, often reading half-lines or more all at once. With camel-case, it is more difficult. With the above, I have to pick through it, and ambiguities are possible as others have shown.

Sincerely,

Gene Wirchenko

2014-06-23 Reply Admin

Jay:
Valued Service:
John:
"upPerson, upperSon" -> give up on camel case, the sooner the better -> up_person, upper_son.
whyWouldWeThinkItsAGoodIdeaToJamWordsTogether

Because separating words was a measure taken to make reading available to the public. Ancient Hebrew didn't separate words, and they didn't have vowels either.

youcanreadthisjustfineifyoutried

wedonotevenneeduppercasetoreadthisorpunctuationforthatmatter

itjusttakesslightlylongertoread

Now I understand how ancient Israel was conquered. A soldier at the front sent back the dire warning, "The Babylonians are now here!", but writing it without spaces, it was interpreted as "The Babylonians are nowhere."

+1

QED

2014-06-23 Reply Admin

Valued Service:
Hasse de great:
Gill Hennessman:
TRWTF:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
This is yet another example of why case-insensitivity is a bloody retarded idea. WTF is so hard about having identifiers be treated exactly as they are? Don't even get me started on all the definitions of "upper" and "lower" across languages...

Most stupid invention in modern programming languages is case sensitive variables. A programmer would never find his way to "Main Street" as the sign says "MAIN STREET"

I'd have to disagree.

While it's an inconvenience, I wouldn't want to allow programmers to code like this.

var MAinsTReet = ... maINSreET = ...

And besides if you use camel case.

upperSon upPerson

are two different things

And this is why SQL Server databases should be developed in a BIN2 environment, because that enforces case-sensitivity for everything, including code. This is why major open source SQL Server projects are so difficult to get running on anything except legacy latin-based environments, because the programmers DO program like that when case sensitivity is not enforced.

Coyne · 2014-06-24 Reply Admin

Fun for DBA's. Create a table with columns like this (showing the SELECT necessary to pull data):

SELECT "Person  Id"
   , "Person Last  Name", "Person  First Name"
   , "PERSON  SsN", "COL_W_%@$#! Junk"
   , "My.Extra.Col", "   B"
FROM """My TAbLE'"

2014-06-24 Reply Admin

Darth Paul:
And this is why SQL Server databases should be developed in a BIN2 environment, because that enforces case-sensitivity for everything, including code. This is why major open source SQL Server projects are so difficult to get running on anything except legacy latin-based environments, because the programmers DO program like that when case sensitivity is not enforced.

This comment a pile of steaming WTF.

Binary collation is a huge WTF. There ARE standard collations for each language, along with a few "master" collations, and none of them are binary collation. We've had the Unicode standard for 20 years, stop trying to turn the clock back to 1970, damn it.

Case-sensitivity should be done on an as-needed basis, not by default. There are very few times in real-life when you actually want case-sensitivity. Even worse, turning on case-sensitivity when it goes against the standard that supposedly governs your work is basically slapping the future maintainers of your code in the face, just to make you feel a little better. Case-sensitivity in code is purely a construct of simpler compilers (and a reaction against the excesses of bad BASIC code); although you can still write in vi/notepad, IDEs could enforce code-formatting standards by the late 80's, obviating the need.

Lastly, if developers don't test anything with an umlaut in the first place, what makes you think that enabling case-sensitive collation will fix that?

Not Your Quotidian Database

Leave a comment on “Not Your Quotidian Database”