Remember you need to get the avg into a string and above all, you need to cast at least one of the variables as numeric otherwise you'll get 0 everywhere. PostgreSQL is awful.

This kata's ROUND as well as DECIMAL keywords did not work on this problem for me. Whenever I tried to use them they didn't 'highlight' like normal keywords should, and then errors said 'no such functions exist'. Is there some setting I need to muddle with?

I fiddled around for at least thirty minutes trying to get it to work without them. Sure enough I clicked through to the solution and nope, everyone has used them just fine. ARGH.

When you use only integers in a division, you will get integer division. When you use (at least one) double or float, you will get floating point division (and the answer you want to get).

So you can declare one or both of the variables as float/double
cast one or both of the variables to float/double.
Do not just cast the result of the integer division to double: the division was already performed as integer division, so the numbers behind the decimal are already lost.

Remember you need to get the avg into a string and above all, you need to cast at least one of the variables as numeric otherwise you'll get 0 everywhere. PostgreSQL is awful.

Nice Kata, but I don't know why we should turn batting_average into a string, ROUND has several problems if you don't try DECIMAL value

And yet it works. Why would you force yourself to do that?

This is whitespace. If you wrap your expression in length(), it will show 6 symbols

This is whitespace. If you wrap your expression in length(), it will show 6 symbols

same issue, even though iam outputting with to_char

Spent over 15 minutes to figure it out, thank you.

Everything works correctly. If you have an issue, it's on your side only.

This kata's ROUND as well as DECIMAL keywords did not work on this problem for me. Whenever I tried to use them they didn't 'highlight' like normal keywords should, and then errors said 'no such functions exist'. Is there some setting I need to muddle with?

I fiddled around for at least thirty minutes trying to get it to work without them. Sure enough I clicked through to the solution and nope, everyone has used them just fine. ARGH.

The "games" collumun is the number of games that the player was in, not something like a game code. There is one row per player, not one row per game.

This comment is hidden because it contains spoiler information about the solution

If you select * from yankees, you'll note that there are only 11 players in the table, however, one of the tests is that the expected rows count 13

Looking at the tests, casting is apparently required

When you use only integers in a division, you will get integer division. When you use (at least one) double or float, you will get floating point division (and the answer you want to get).

So you can declare one or both of the variables as float/double

cast one or both of the variables to float/double.

Do not just cast the result of the integer division to double: the division was already performed as integer division, so the numbers behind the decimal are already lost.

from: https://stackoverflow.com/questions/1666407/sql-server-division-returns-zero

## Loading more items...