• SorteKanin@feddit.dk
    link
    fedilink
    arrow-up
    0
    ·
    11 months ago

    Same, I prefer lower case. Every other language has keywords in lower case, why do you need to shout when writing sql?

    • hikaru755@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      11 months ago

      I understand it as an attempt to get very basic, manual syntax highlighting. If all you have is white text on black background, then I do see the value of making keywords easy to spot by putting them in all caps. And this probably made sense back when SQL was first developed, but it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times

      • Stumblinbear@pawb.social
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        11 months ago

        Please tell me what IDE you’re using that’s capable of highlighting SQL syntax that’s embedded inside another language source file

        Also please fucking stop with the “it’s current year stop x.” The year is not an argument.

        • hikaru755@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          11 months ago

          As the other commenter said, the Jetbrains IDEs do this perfectly fine. Although I’d also argue that if you’re working with SQL from within another language already, a DSL wrapper is probably gonna be the better way to go about this.

          • Stumblinbear@pawb.social
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            11 months ago

            Unfortunately RustRover is still garbage for actual usage. And I refuse to use an ORM when I can just write the SQL in a more common syntax that everyone understands across every language instead of whatever inefficient library-of-the-week there is. Raw SQL is fine and can be significantly more performant. Don’t be scared.

            • hikaru755@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              11 months ago

              I’m not talking full blown ORM here, not a fan of those either. I’m talking about some light weight wrapper that basically just assembles SQL statements for you, while giving you just a little more type safety and automatic protection against SQL injection, and not sacrificing any performance. I’m coming from the JVM world, where Jooq and Exposed are examples of that kind of thing.

              • Stumblinbear@pawb.social
                link
                fedilink
                arrow-up
                0
                ·
                edit-2
                11 months ago

                I’m currently using SQLx which you write raw queries in and it validates them against a currently-running db, using the description of the tables to build the typing for the return type instead of relying on the user. It makes it pretty hard to write anything that supports injection

                • hikaru755@feddit.de
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  11 months ago

                  Oh, that sounds really cool! At what time does this validation happen? While you code, or later at build time?

      • jaybone@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        11 months ago

        Also some people are color blind.

        Also you might need to ssh in somewhere and vi some code or tail a log file where you don’t have color support.

        • hikaru755@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          11 months ago

          My ide isn’t limited to color when it comes to highlighting, so being color blind generally shouldn’t be a problem. Set keywords to underlined, bold, italic, whatever works for you.

          Your other examples I can see, but at least at my work those are rare edge cases, and I’d rather optimize for the brunt of the work than for those. Of course at other places those might be much more of a concern.