The Prisma engine is written in Rust (and the original product was written in Scala), so your snide comment is actually a bit inaccurate. You've also ironically failed to spell JavaScript using the correct casing.
Thats not particular to postgres, that's the same in Oracle (or any other db following ISO case handling I believe), just with true (quoted) table name being all uppercase instead for the latter but with same error.
You can quote the table name in the create statement to get the camelcase table name. Just remember to quote in both creation and usage or neither, is a good rule of thumb
I'm not super well versed in this domain, but I believe Postgres columns need to be wrapped in double quotes to respect case, or else they're all treated as lower, or something along those lines?
That's largely only true for schema names and table names, not all identifiers.
The original root cause was having schemas backed by directories, and table definitions backed by .frm files. So on a case-insensitive filesystem like on Windows or MacOS, MySQL enables corresponding case-insensitivity logic for the affected types of identifiers.
I can't speak much in detail, but maybe the following will paint you a picture.
I did contract work for a large international financial institution, known for being "one of the big N" (N<5). Lots of data/backend/db work, in several languages/stacks. Then a new style/naming convention for databases got pushed, by middle/higher management. It included identifiers in both camel-case and pascal-case. It was clearly "designed" by somebody with a programming background in languages that use similar conventions.
I noticed how there would be trouble ahead, because databases have (often implicit) naming conventions of their own. Not without reason. They have been adopted (or "discovered") by more seasoned database engineers, usually first and foremost as for causing the least chance of interoperability issues. Often it is technically possible to deviate from them (your db vendor XYZ might support it), but the trouble typically doesn't emerge on the database level itself. Instead it is tooling and programming languages/frameworks on top of it, where things start to fall apart when deviating from the conventional wisdom of database naming conventions.
That also happened with that client. Turned out that the two major languages/frameworks/stacks they used for all their in-house projects (as well as many external product/services), fell apart on incompatibility with the new styling/naming conventions. All internal issues, with undocumented details (lots of low-level debugging to even find the issues). I already had predicted it beforehand, saw it coming, reported it, but got ignored. Not long after, I was "let go". Maybe because of tightened budgets, maybe because several projects hit a wall (not going anywhere, in large part because of the above mentioned f#-up). I'm sure the person who original caused the situation still got royally paid, bonuses included, regardless.
Anyways, the moral of the story here is this: even if you technically could deviate from well established database naming conventions, you can get yourself in a world of hurt if you do. Also if it appears to resolve naming inconsistencies with programming languages of choice.
This has nothing to do with Windows. EF Core just happens to be best-in-class ORM, unlike the "ORMs" on other platforms which give the concept bad rep.
The camel-casing makes life hard because any manual queries you write, you need to quote the names AND uppercase certain letters, as well as the fact its just inconsistent.
I imagine most people using this will rarely write a manual query. ORMs are extremely common in JS land these days. I don’t like it, but to each their own.
I imagine that the people who use CamelCase table names will one day make some analysts and data scientists very sad, assuming the company they work for grows large enough to hire them.
