• (cs)

    Those fristy Siberian winters...

  • Iggy (unregistered)

    how would SQL injection work in this case?

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

    so improved security

  • Anonymous (unregistered)

    Better than this:

    <php echo "var content = {"type":"comment","serialized":"{\"poster\":\"Anonymous\",\"message\":\"I say, I \\\"really\\\" love quotes.\"}"}"; ?>

  • (cs)

    Can I quote you on that?

  • Funnyguy (unregistered)

    TRWTF is Postgres

  • Dave (unregistered)

    Fitfh

  • anon (unregistered) in reply to Dave
    Dave:
    Fitfh

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

  • Gill Hennessman (unregistered)

    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...
  • Smug Unix User (unregistered)

    ALLOWING CASE IS OVERRATED

  • Quote Endquote (unregistered)

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

  • Hasse de great (unregistered) in reply to Gill Hennessman
    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"

  • (cs)
    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?
  • (cs) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    Siberia is historically a place where troublemakers were sent, so where do you send troublemakers like Vitaly who are already in Siberia?

    Detroit.

  • (cs) in reply to Nook Schreier
    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.

  • Jeff Grigg (unregistered)

    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.)

  • huppenzuppen (unregistered)

    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?

  • anonymous (unregistered)

    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.

  • Harrow (unregistered) in reply to Hasse de great
    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.

  • Mr. AHole DBA Guy (unregistered) in reply to Funnyguy
    Funnyguy:
    TRWTF is Postgres

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

  • anonymous (unregistered) in reply to huppenzuppen
    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
  • anonymous (unregistered) in reply to Harrow
    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.

  • Valued Service (unregistered) in reply to Hasse de great
    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

  • anonymous (unregistered) in reply to Valued Service
    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.

  • eman_ruoy (unregistered) in reply to PedanticCurmudgeon
    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!

  • (cs) in reply to Gill Hennessman
    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?
  • Mike (unregistered)

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

  • Valued Service (unregistered) in reply to anonymous
    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.

  • foo AKA fooo (unregistered) in reply to Valued Service
    Valued Service:
    And besides if you use camel case.

    upperSon upPerson

    are two different things

      if (gotHere ())
    goThere ();

  • (cs) in reply to nerd4sale
    nerd4sale:
    Those fristy Siberian winters...

    Frist quote of "frist" post.

  • (cs) in reply to Valued Service
    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.

  • (cs)

    So using single quotes in the shell like

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

    was too good for him?

  • John (unregistered)

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

    whyWouldWeThinkItsAGoodIdeaToJamWordsTogether

  • Ren Bussell (unregistered)

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

  • Valued Service (unregistered) in reply to John
    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

  • quux (unregistered) in reply to foo AKA fooo
    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"; 

  • Valued Service (unregistered) in reply to quux
    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.

  • Not Douglas Adams (unregistered) in reply to Valued Service
    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

  • Jay (unregistered) in reply to Gill Hennessman
    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.

  • Jay (unregistered) in reply to Valued Service
    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.

  • Jay (unregistered) in reply to Valued Service
    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."

  • Bob (unregistered) in reply to Valued Service

    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.

  • Nagesh (unregistered)

    Why not use "[]" brackets?

  • Tux "Tuxedo" Penguin (unregistered) in reply to foo AKA fooo
    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()

  • Hasse de great (unregistered) in reply to Bob
    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.

  • Reductio Ad Ridiculousum (unregistered) in reply to Hasse de great
    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'

  • (cs) in reply to Valued Service
    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

  • RedWizard (unregistered) in reply to Jay
    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

  • Darth Paul (unregistered) in reply to Valued Service
    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.

  • (cs)

    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'"
    
  • foxyshadis (unregistered) in reply to Darth Paul
    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?

Leave a comment on “Not Your Quotidian Database”

Log In or post as a guest

Replying to comment #435722:

« Return to Article