Quote `randomNumber` column in PostgreSQL schema

[jonathanhefner]

I've opened this PR because it is a point of frustration when implementing tests for new frameworks, but I've marked it as draft because the change may be too breaking.

The test specs say that the World table has an id column and randomNumber column (note the camelCasing). Indeed, the PostgreSQL schema uses randomNumber in its CREATE TABLE statement. However, the CREATE TABLE statement does not quote the column name, so PostgreSQL treats the name as if it were lowercase.

Also note that the PostgreSQL schema has CREATE TABLE World and CREATE TABLE "World" statements. Presumably, this is because the former actually creates a world table because it too is not quoted. (Whereas the latter actually creates a World table.)

This commit modifies the CREATE TABLE "World" statement to quote the randomNumber column so that its camel case is preserved.

[msmith-techempower]

So, the impact here is that anyone making a query with the non-quoted version will be in error?

[jonathanhefner]

So, the impact here is that anyone making a query with the non-quoted version will be in error?

Correct.

Before this PR:

> SELECT "randomNumber" FROM "World" LIMIT 1;
ERROR:  column "randomNumber" does not exist
LINE 1: SELECT "randomNumber" FROM "World" LIMIT 1;
               ^
HINT:  Perhaps you meant to reference the column "World.randomnumber".


> SELECT randomNumber FROM "World" LIMIT 1;
 randomnumber
--------------
         2338
(1 row)

After this PR:

> SELECT "randomNumber" FROM "World" LIMIT 1;
 randomNumber
--------------
         5197
(1 row)


> SELECT randomNumber FROM "World" LIMIT 1;
ERROR:  column "randomnumber" does not exist
LINE 1: SELECT randomNumber FROM "World" LIMIT 1;
               ^
HINT:  Perhaps you meant to reference the column "World.randomNumber".

[msmith-techempower]

I'm doing kind of a "spring cleaning" of these legacy PRs. Here's my thinking on this one:

I think this has potential, but I don't want to start failing tests for switching over from requiring no quotes to suddenly requiring them - there are a lot of codebases and ORMs that would probably be impacted. A better solution, imho, is to support both. I thought of just adding both columns to your PR, but it occurred to me that perhaps there are implementations using SELECT * ... which would now have an additional column that might bleed into outputs.

So, I'm closing for now, but feel free to reopen if you want to take up the mantle on this issue.