You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've gotten everything working with my PostgresQL database, and noticed that all my BIGINT columns get returned as a string in the resulting Typescript interfaces.
I came across #15, which acknowledges this behavior and results in it being added for MySQL too. But I was wondering why the String approach was chosen instead of using the Javascript BigInt primitive.
Intuitively, it makes more sense to me to use and return BigInts as it corresponds more directly with the real data, but I assume there is a reasoning (compatibility?) for using a simple String instead.
In some rare cases, I want to compare two BIGINT values, say A > B, which works fine with Strings until one has more digits (e.g. '999' > '1000' results in true). Should I just find a work-around for these cases (maybe use some padding zeroes to start), or is there some sense in allowing the use of the BigInt primitive instead of a string?
And as an additional question, are there any options to influence the type mapping from the column types in my schema at all?
The text was updated successfully, but these errors were encountered:
I think it's to keep sqlc simple. Just to keep it a thin wrapper for each DB driver libs.
Since node-mysql2 only supports number or string for BIGINT, converting to JavaScript BigInt type adds extra complexity to sqlc.
Thank you for this cool and useful utility!
I've gotten everything working with my PostgresQL database, and noticed that all my
BIGINT
columns get returned as astring
in the resulting Typescriptinterface
s.I came across #15, which acknowledges this behavior and results in it being added for MySQL too. But I was wondering why the String approach was chosen instead of using the Javascript
BigInt
primitive.Intuitively, it makes more sense to me to use and return
BigInt
s as it corresponds more directly with the real data, but I assume there is a reasoning (compatibility?) for using a simple String instead.In some rare cases, I want to compare two
BIGINT
values, sayA > B
, which works fine with Strings until one has more digits (e.g.'999' > '1000'
results intrue
). Should I just find a work-around for these cases (maybe use some padding zeroes to start), or is there some sense in allowing the use of theBigInt
primitive instead of astring
?And as an additional question, are there any options to influence the type mapping from the column types in my schema at all?
The text was updated successfully, but these errors were encountered: