Always use BIGINT macro for 'long long' data by mike-myers-tob · Pull Request #6...
source link: https://github.com/osquery/osquery/pull/6986
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
Following up on #6897 this is basically the same deal: always use the BIGINT macro rather than the INTEGER macro when dealing with long long values, or they might generate warnings and not report data, the same as explained in the last PR.
You can enforce the schema with a small heuristic similar to https://github.com/osquery/osquery/blob/master/tools/codegen/gentable.py#L415
My thought was to look for columns named *_time or named time and enforce they are type BIGINT.
You can enforce the schema with a small heuristic similar to https://github.com/osquery/osquery/blob/master/tools/codegen/gentable.py#L415
My thought was to look for columns named
*_timeor namedtimeand enforce they are typeBIGINT.
Table gen spec file is a bit of internal magic I am not familiar with, but that looks like a relatively simple change, someone just has to generalize that check already being done currently for _events tables?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No one assigned
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK