{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":387622288,"defaultBranch":"main","name":"vsql","ownerLogin":"elliotchance","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2021-07-19T23:55:45.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/927418?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1713723855.0","currentOid":""},"activityList":{"items":[{"before":"5f7596e58cc9bb378ee34d00923612adabf77680","after":"60e737250a82cd1537b443a133bdb13e1111b29c","ref":"refs/heads/main","pushedAt":"2024-04-23T17:17:29.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"chore: add `v.mod` manifest file (#191)","shortMessageHtmlLink":"chore: add <code>v.mod</code> manifest file (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2229312760\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/191\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/191/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/191\">#191</a>)"}},{"before":"9e8fbbba7671921bd5380125e66da8d33ab3e09b","after":null,"ref":"refs/heads/v-up-5","pushedAt":"2024-04-21T18:23:16.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"}},{"before":"2b4bf7aee454292d07cf97a347b78c2ec9f0213f","after":"5f7596e58cc9bb378ee34d00923612adabf77680","ref":"refs/heads/main","pushedAt":"2024-04-21T18:23:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"v: Update to V 0.4.5 ed7f1ff (#196)\n\nThis aggregates the awesome work by @ttytm in #192, #193, #194 and #195.","shortMessageHtmlLink":"v: Update to V 0.4.5 ed7f1ff (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2254521812\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/196\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/196/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/196\">#196</a>)"}},{"before":"750bdb3041c742eec05edb30781f9672d9924b89","after":"9e8fbbba7671921bd5380125e66da8d33ab3e09b","ref":"refs/heads/v-up-5","pushedAt":"2024-04-20T12:44:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"v: Update to V 0.4.5 ed7f1ff","shortMessageHtmlLink":"v: Update to V 0.4.5 ed7f1ff"}},{"before":"3e1ff5caa228101aedd81b4761ddad1e6419e912","after":"750bdb3041c742eec05edb30781f9672d9924b89","ref":"refs/heads/v-up-5","pushedAt":"2024-04-20T12:15:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"v: Update to V 0.4.5 ed7f1ff","shortMessageHtmlLink":"v: Update to V 0.4.5 ed7f1ff"}},{"before":null,"after":"3e1ff5caa228101aedd81b4761ddad1e6419e912","ref":"refs/heads/v-up-5","pushedAt":"2024-04-20T12:02:25.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"v: Update to V 0.4.5 ed7f1ff","shortMessageHtmlLink":"v: Update to V 0.4.5 ed7f1ff"}},{"before":"3e1ff5caa228101aedd81b4761ddad1e6419e912","after":"2b4bf7aee454292d07cf97a347b78c2ec9f0213f","ref":"refs/heads/main","pushedAt":"2024-04-20T12:00:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"docs: update description of `make cli-test` in testing.rst (#188)\n\nupdate description of `make cli-test` in testing.rst, to match the name of the make target","shortMessageHtmlLink":"docs: update description of <code>make cli-test</code> in testing.rst (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2061800039\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/188\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/188/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/188\">#188</a>)"}},{"before":"2b4bf7aee454292d07cf97a347b78c2ec9f0213f","after":"3e1ff5caa228101aedd81b4761ddad1e6419e912","ref":"refs/heads/main","pushedAt":"2024-04-20T11:58:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"v: Update to V 0.4.5 ed7f1ff","shortMessageHtmlLink":"v: Update to V 0.4.5 ed7f1ff"}},{"before":"16087e341f590b1f6aaa2e4557582e2dee32aa14","after":"2b4bf7aee454292d07cf97a347b78c2ec9f0213f","ref":"refs/heads/main","pushedAt":"2024-01-02T08:15:15.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"docs: update description of `make cli-test` in testing.rst (#188)\n\nupdate description of `make cli-test` in testing.rst, to match the name of the make target","shortMessageHtmlLink":"docs: update description of <code>make cli-test</code> in testing.rst (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2061800039\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/188\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/188/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/188\">#188</a>)"}},{"before":"061e53a315b6930d367880a8804172e56f4c735c","after":"16087e341f590b1f6aaa2e4557582e2dee32aa14","ref":"refs/heads/main","pushedAt":"2024-01-02T08:13:15.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"fix compilation notice with latest V (#189)","shortMessageHtmlLink":"fix compilation notice with latest V (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2061803280\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/189\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/189/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/189\">#189</a>)"}},{"before":"a220a6d6c1db46e32af620fa93a4dd4eed3be0b2","after":"dc6a494b2a17f4e79092cd32be0282b56ce3d770","ref":"refs/heads/i90-orm","pushedAt":"2023-12-31T15:22:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"Support for the V ORM\n\nDO NOT MERGE.\n\nThis is partial support for the ORM. However, there are some challenges\nthat need to be addressed before this can be properly reviewed and\nlanded:\n\n1. The ORM in V requires drivers to be hard-coded. See #90.\n\n2. The Connection doesn't _really_ implement orm.Connection because the\nvsql Connection is required to be mut and the current interface\ndefinition does not allow this.\n\n3. We need to create a new test suite for the ORM. `vsql/orm_test.v`\nfilled with combinations of statements \"sql\" commands will work just\nfine. Specifically, we need to test different combinations of\nexpressions and types.\n\nFixes #90","shortMessageHtmlLink":"Support for the V ORM"}},{"before":"8d76f33c3de384ab34a77d8f2473ac80306eccec","after":"a220a6d6c1db46e32af620fa93a4dd4eed3be0b2","ref":"refs/heads/i90-orm","pushedAt":"2023-12-30T17:29:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"Support for the V ORM\n\nDO NOT MERGE.\n\nThis is partial support for the ORM. However, there are some challenges\nthat need to be addressed before this can be properly reviewed and\nlanded:\n\n1. The ORM in V requires drivers to be hard-coded. See #90.\n\n2. The Connection doesn't _really_ implement orm.Connection because the\nvsql Connection is required to be mut and the current interface\ndefinition does not allow this.\n\n3. We need to create a new test suite for the ORM. `vsql/orm_test.v`\nfilled with combinations of statements \"sql\" commands will work just\nfine. Specifically, we need to test different combinations of\nexpressions and types.\n\nFixes #90","shortMessageHtmlLink":"Support for the V ORM"}},{"before":"c621c5ea132eb3c07e84f8db49b715aed9db64e7","after":"8d76f33c3de384ab34a77d8f2473ac80306eccec","ref":"refs/heads/i90-orm","pushedAt":"2023-12-30T10:56:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"Support for the V ORM\n\nDO NOT MERGE.\n\nThis is partial support for the ORM. However, there are some challenges\nthat need to be addressed before this can be properly reviewed and\nlanded:\n\n1. The ORM in V requires drivers to be hard-coded. See #90.\n\n2. The Connection doesn't _really_ implement orm.Connection because the\nvsql Connection is required to be mut and the current interface\ndefinition does not allow this.\n\n3. We need to create a new test suite for the ORM. `vsql/orm_test.v`\nfilled with combinations of statements \"sql\" commands will work just\nfine. Specifically, we need to test different combinations of\nexpressions and types.\n\nFixes #90","shortMessageHtmlLink":"Support for the V ORM"}},{"before":"3f5452bbcc6c0a86cf401bf148f7966af0421a04","after":null,"ref":"refs/heads/swap-decimal-numeric","pushedAt":"2023-12-30T00:04:36.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"}},{"before":"9895e3b513c14ebb9a6c3e3b04ac5230bac01241","after":"061e53a315b6930d367880a8804172e56f4c735c","ref":"refs/heads/main","pushedAt":"2023-12-30T00:04:32.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"numbers: Swap NUMERIC and DECIMAL (#187)\n\nI made a mistake, confusing the names of NUMERIC vs DECIMAL. NUMERIC is\r\nactually the exact type and DECIMAL is the more relaxed type, rather\r\nthan the other way around. For prosperity, the *only* difference between\r\nthese two types in the SQL standard is:\r\n\r\nISO/IEC 9075-2:2016(E), 6.1, <data type>, Syntax Rules:\r\n\r\n> 26) NUMERIC specifies the data type exact numeric, with the decimal\r\n> precision and scale specified by the <precision> and <scale>.\r\n>\r\n> 27) DECIMAL specifies the data type exact numeric, with the decimal\r\n> scale specified by the <scale> and the implementation-defined decimal\r\n> precision equal to or greater than the value of the specified\r\n> <precision>.\r\n\r\nI have seen this interpreted as: DECIMAL can use more precision (than\r\nspecified) if it's more storage efficient or otherwise favorable for the\r\nengine to do so. This is the reasoning behind vsql's DECIMAL\r\nimplementation of storing the raw fraction instead of scaling the number\r\nto the exact NUMERIC value.\r\n\r\nThis also fixes:\r\n\r\n1. All exact numeric types (DECIMAL, NUMERIC, SMALLINT, INTEGER and\r\nBIGINT) were being converted to approximate types for comparison (=, >,\r\netc). They are now compared as exact values.\r\n\r\n2. Nowhere does it say say in the standard that exact values should be\r\nzero padded to the precision (ie. 1.200 for NUMERIC(4, 3)). In fact, it\r\nactually specifies that when converting an exact type to a\r\nvariable-length character string it should not do that:\r\n\r\nISO/IEC 9075-2:2016(E), 6.13, <cast specification>, General Rules:\r\n\r\n> 12) a) i) Let YP be the shortest character string that conforms to the\r\n> definition of <exact numeric literal> in Subclause 5.3, \"<literal>\",\r\n> whose scale is the same as the scale of SD and whose interpreted value\r\n> is the absolute value of SV.\r\n\r\nIt could be argued that the string/display values do not need to follow\r\nthis same specification as the situation is different. However, I think\r\nit's going to be less confusing long term if we treat these conversions\r\nthe same everywhere.\r\n\r\n3. Fixed a bug where casting a DECIMAL to DECIMAL of a higher\r\nprecision would not result in more actual precision as expected.","shortMessageHtmlLink":"numbers: Swap NUMERIC and DECIMAL (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2060461847\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/187\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/187/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/187\">#187</a>)"}},{"before":null,"after":"3f5452bbcc6c0a86cf401bf148f7966af0421a04","ref":"refs/heads/swap-decimal-numeric","pushedAt":"2023-12-29T23:35:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"numbers: Swap NUMERIC and DECIMAL\n\nI made a mistake, confusing the names of NUMERIC vs DECIMAL. NUMERIC is\nactually the exact type and DECIMAL is the more relaxed type, rather\nthan the other way around. For prosperity, the *only* difference between\nthese two types in the SQL standard is:\n\nISO/IEC 9075-2:2016(E), 6.1, <data type>, Syntax Rules:\n\n> 26) NUMERIC specifies the data type exact numeric, with the decimal\n> precision and scale specified by the <precision> and <scale>.\n>\n> 27) DECIMAL specifies the data type exact numeric, with the decimal\n> scale specified by the <scale> and the implementation-defined decimal\n> precision equal to or greater than the value of the specified\n> <precision>.\n\nI have seen this interpreted as: DECIMAL can use more precision (than\nspecified) if it's more storage efficient or otherwise favorable for the\nengine to do so. This is the reasoning behind vsql's DECIMAL\nimplementation of storing the raw fraction instead of scaling the number\nto the exact NUMERIC value.\n\nThis also fixes:\n\n1. All exact numeric types (DECIMAL, NUMERIC, SMALLINT, INTEGER and\nBIGINT) were being converted to approximate types for comparison (=, >,\netc). They are now compared as exact values.\n\n2. Nowhere does it say say in the standard that exact values should be\nzero padded to the precision (ie. 1.200 for NUMERIC(4, 3)). In fact, it\nactually specifies that when converting an exact type to a\nvariable-length character string it should not do that:\n\nISO/IEC 9075-2:2016(E), 6.13, <cast specification>, General Rules:\n\n> 12) a) i) Let YP be the shortest character string that conforms to the\n> definition of <exact numeric literal> in Subclause 5.3, \"<literal>\",\n> whose scale is the same as the scale of SD and whose interpreted value\n> is the absolute value of SV.\n\nIt could be argued that the string/display values do not need to follow\nthis same specification as the situation is different. However, I think\nit's going to be less confusing long term if we treat these conversions\nthe same everywhere.\n\n3. Fixed a bug where casting a DECIMAL to DECIMAL of a higher\nprecision would not result in more actual precision as expected.","shortMessageHtmlLink":"numbers: Swap NUMERIC and DECIMAL"}},{"before":"62e505d365ce14996aded75d3c494255d89df1b6","after":null,"ref":"refs/heads/numeric-decimal","pushedAt":"2023-12-24T17:48:43.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"}},{"before":"2a1989aa37ea7b2aeeb5e7ad9b13fcac29779e82","after":"9895e3b513c14ebb9a6c3e3b04ac5230bac01241","ref":"refs/heads/main","pushedAt":"2023-12-24T17:48:39.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"Adding NUMERIC and DECIMAL types (#186)\n\n`NUMERIC` and `DECIMAL` types are used for arbitrary precision exact\r\nnumbers. This has a been long in development. It's required several\r\nrewrites and some major changes and improvements to vsql in previous\r\nversions to lay the foundation for these types to be fully integrated as\r\nfirst class citizens.\r\n\r\nNow, number literals that contains a '.' (even if they are a whole\r\nnumbers such as `123.`) are treated as `NUMERIC` with the scale and\r\nprecision determined from the number. Arithmetic operations can result\r\nin types that are higher in scale and precision, according to the\r\nstandard (which is very specific about all of that).\r\n\r\nAs far as I'm aware vsql is the only SQL database to treat these as\r\ndistinct types according to the standard, rather than being aliases of\r\nthe same underlying type. In a nutshell, `NUMERIC` and `DECIMAL` are\r\nboth stored as fractions, but `NUMERIC` permits any denominator within\r\nrange, whereas a `DECIMAL` must have a base 10 denominator. You can\r\nthink of `DECIMAL` as having \"exactly\" the precision specified (i.e good\r\nfor currency), but `NUMERIC` has \"at least\" the precision specified.\r\nMeaning it's possible to `CAST` a `NUMERIC` to a higher precision and\r\nget more decimal places (from the inherent nature of a fraction). The\r\ndocs explain this much better, with examples.\r\n\r\nSince this does introduce new storage types, a database file version\r\nbump is required but this likely be the last version bump before v1.0.0\r\nis released.\r\n\r\nAlong with the two new SQL types, there are some functions that work\r\ndirectly with exact numbers: `ABS`, `CEIL`, `FLOOR` and `MOD`.\r\n\r\nSQL Standard E011-03","shortMessageHtmlLink":"Adding NUMERIC and DECIMAL types (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2055146091\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/186\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/186/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/186\">#186</a>)"}},{"before":"bed7f2b190790c51e7968863574bfb52696d0508","after":"62e505d365ce14996aded75d3c494255d89df1b6","ref":"refs/heads/numeric-decimal","pushedAt":"2023-12-24T17:36:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"Adding NUMERIC and DECIMAL types\n\n`NUMERIC` and `DECIMAL` types are used for arbitrary precision exact\nnumbers. This has a been long in development. It's required several\nrewrites and some major changes and improvements to vsql in previous\nversions to lay the foundation for these types to be fully integrated as\nfirst class citizens.\n\nNow, number literals that contains a '.' (even if they are a whole\nnumbers such as `123.`) are treated as `NUMERIC` with the scale and\nprecision determined from the number. Arithmetic operations can result\nin types that are higher in scale and precision, according to the\nstandard (which is very specific about all of that).\n\nAs far as I'm aware vsql is the only SQL database to treat these as\ndistinct types according to the standard, rather than being aliases of\nthe same underlying type. In a nutshell, `NUMERIC` and `DECIMAL` are\nboth stored as fractions, but `NUMERIC` permits any denominator within\nrange, whereas a `DECIMAL` must have a base 10 denominator. You can\nthink of `DECIMAL` as having \"exactly\" the precision specified (i.e good\nfor currency), but `NUMERIC` has \"at least\" the precision specified.\nMeaning it's possible to `CAST` a `NUMERIC` to a higher precision and\nget more decimal places (from the inherent nature of a fraction). The\ndocs explain this much better, with examples.\n\nSince this does introduce new storage types, a database file version\nbump is required but this likely be the last version bump before v1.0.0\nis released.\n\nAlong with the two new SQL types, there are some functions that work\ndirectly with exact numbers: `ABS`, `CEIL`, `FLOOR` and `MOD`.\n\nSQL Standard E011-03","shortMessageHtmlLink":"Adding NUMERIC and DECIMAL types"}},{"before":"3cbb4f476a2f52130e28546c92057f0f4135e735","after":"bed7f2b190790c51e7968863574bfb52696d0508","ref":"refs/heads/numeric-decimal","pushedAt":"2023-12-24T15:54:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"Adding NUMERIC and DECIMAL types\n\n`NUMERIC` and `DECIMAL` types are used for arbitrary precision exact\nnumbers. This has a been long in development. It's required several\nrewrites and some major changes and improvements to vsql in previous\nversions to lay the foundation for these types to be fully integrated as\nfirst class citizens.\n\nNow, number literals that contains a '.' (even if they are a whole\nnumbers such as `123.`) are treated as `NUMERIC` with the scale and\nprecision determined from the number. Arithmetic operations can result\nin types that are higher in scale and precision, according to the\nstandard (which is very specific about all of that).\n\nAs far as I'm aware vsql is the only SQL database to treat these as\ndistinct types according to the standard, rather than being aliases of\nthe same underlying type. In a nutshell, `NUMERIC` and `DECIMAL` are\nboth stored as fractions, but `NUMERIC` permits any denominator within\nrange, whereas a `DECIMAL` must have a base 10 denominator. You can\nthink of `DECIMAL` as having \"exactly\" the precision specified (i.e good\nfor currency), but `NUMERIC` has \"at least\" the precision specified.\nMeaning it's possible to `CAST` a `NUMERIC` to a higher precision and\nget more decimal places (from the inherent nature of a fraction). The\ndocs explain this much better, with examples.\n\nSince this does introduce new storage types, a database file version\nbump is required but this likely be the last version bump before v1.0.0\nis released.\n\nAlong with the two new SQL types, there are some functions that work\ndirectly with exact numbers: `ABS`, `CEIL`, `FLOOR` and `MOD`.\n\nSQL Standard E011-03","shortMessageHtmlLink":"Adding NUMERIC and DECIMAL types"}},{"before":"bb3551d90747a0600cb1ce8474b9ec6181d2f706","after":"3cbb4f476a2f52130e28546c92057f0f4135e735","ref":"refs/heads/numeric-decimal","pushedAt":"2023-12-24T15:53:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"Adding NUMERIC and DECIMAL types\n\n`NUMERIC` and `DECIMAL` types are used for arbitrary precision exact\nnumbers. This has a been long in development. It's required several\nrewrites and some major changes and improvements to vsql in previous\nversions to lay the foundation for these types to be fully integrated as\nfirst class citizens.\n\nNow, number literals that contains a '.' (even if they are a whole\nnumbers such as `123.`) are treated as `NUMERIC` with the scale and\nprecision determined from the number. Arithmetic operations can result\nin types that are higher in scale and precision, according to the\nstandard (which is very specific about all of that).\n\nAs far as I'm aware vsql is the only SQL database to treat these as\ndistinct types according to the standard, rather than being aliases of\nthe same underlying type. In a nutshell, `NUMERIC` and `DECIMAL` are\nboth stored as fractions, but `NUMERIC` permits any denominator within\nrange, whereas a `DECIMAL` must have a base 10 denominator. You can\nthink of `DECIMAL` as having \"exactly\" the precision specified (i.e good\nfor currency), but `NUMERIC` has \"at least\" the precision specified.\nMeaning it's possible to `CAST` a `NUMERIC` to a higher precision and\nget more decimal places (from the inherent nature of a fraction). The\ndocs explain this much better, with examples.\n\nSince this does introduce new storage types, a database file version\nbump is required but this likely be the last version bump before v1.0.0\nis released.\n\nAlong with the two new SQL types, there are some functions that work\ndirectly with exact numbers: `ABS`, `CEIL`, `FLOOR` and `MOD`.\n\nSQL Standard E011-03","shortMessageHtmlLink":"Adding NUMERIC and DECIMAL types"}},{"before":"c621f9c1ac66f69b63e3a39a8b57714e73ac22d1","after":null,"ref":"refs/heads/approximate-numeric-literal","pushedAt":"2023-12-24T01:40:26.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"}},{"before":"1a22339166cd3f0f319bf3b0cd92239b4926814e","after":"2a1989aa37ea7b2aeeb5e7ad9b13fcac29779e82","ref":"refs/heads/main","pushedAt":"2023-12-24T01:40:23.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"language: Added approximate number literals (#185)\n\nThis turned out to be a much more involved change that I expected. It\r\nstarted by adding syntax support for scientific notation (i.e. 32e5) but\r\nended up overhauling how numbers work in vsql, and solving some major\r\ncurrent and future problems.\r\n\r\nAll literals in scientific notation are considered `DOUBLE PRECISION`,\r\nthat part is pretty straightforward. Furthermore, all approximate\r\nnumbers are always formatted in scientific notation, even if smaller\r\nnumbers are given a \"e0\" suffix.\r\n\r\nSince this means that exact and approximate numbers now have a different\r\nform we can take a lot of hacky and unreliable guess work out of\r\nliterals and implicit casting.\r\n\r\n`REAL` and `DOUBLE PRECISION` no longer need to be treated as supertypes\r\nfor all other exact types. Which in retrospect makes no sense. The docs\r\nmake much more sense on how numbers work and this makes the larger\r\nchange of DECIMAL and NUMERIC types coming later much easier to explain\r\nand implement.","shortMessageHtmlLink":"language: Added approximate number literals (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2054904818\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/185\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/185/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/185\">#185</a>)"}},{"before":"e3ef4ccd307b701f4480938373c339a22d241153","after":"c621f9c1ac66f69b63e3a39a8b57714e73ac22d1","ref":"refs/heads/approximate-numeric-literal","pushedAt":"2023-12-23T22:48:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"language: Added approximate number literals\n\nThis turned out to be a much more involved change that I expected. It\nstarted by adding syntax support for scientific notation (i.e. 32e5) but\nended up overhauling how numbers work in vsql, and solving some major\ncurrent and future problems.\n\nAll literals in scientific notation are considered `DOUBLE PRECISION`,\nthat part is pretty straightforward. Furthermore, all approximate\nnumbers are always formatted in scientific notation, even if smaller\nnumbers are given a \"e0\" suffix.\n\nSince this means that exact and approximate numbers now have a different\nform we can take a lot of hacky and unreliable guess work out of\nliterals and implicit casting.\n\n`REAL` and `DOUBLE PRECISION` no longer need to be treated as supertypes\nfor all other exact types. Which in retrospect makes no sense. The docs\nmake much more sense on how numbers work and this makes the larger\nchange of DECIMAL and NUMERIC types coming later much easier to explain\nand implement.","shortMessageHtmlLink":"language: Added approximate number literals"}},{"before":"4dde1da8a1cbc3a39d3d33232cd1604840beb8e8","after":"e3ef4ccd307b701f4480938373c339a22d241153","ref":"refs/heads/approximate-numeric-literal","pushedAt":"2023-12-23T22:42:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"language: Added approximate number literals\n\nThis turned out to be a much more involved change that I expected. It\nstarted by adding syntax support for scientific notation (i.e. 32e5) but\nended up overhauling how numbers work in vsql, and solving some major\ncurrent and future problems.\n\nAll literals in scientific notation are considered `DOUBLE PRECISION`,\nthat part is pretty straightforward. Furthermore, all approximate\nnumbers are always formatted in scientific notation, even if smaller\nnumbers are given a \"e0\" suffix.\n\nSince this means that exact and approximate numbers now have a different\nform we can take a lot of hacky and unreliable guess work out of\nliterals and implicit casting.\n\n`REAL` and `DOUBLE PRECISION` no longer need to be treated as supertypes\nfor all other exact types. Which in retrospect makes no sense. The docs\nmake much more sense on how numbers work and this makes the larger\nchange of DECIMAL and NUMERIC types coming later much easier to explain\nand implement.","shortMessageHtmlLink":"language: Added approximate number literals"}},{"before":"766a41a36dda4f33afa934c41786a89104af5d03","after":"4dde1da8a1cbc3a39d3d33232cd1604840beb8e8","ref":"refs/heads/approximate-numeric-literal","pushedAt":"2023-12-23T22:31:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"language: Added approximate number literals\n\nThis turned out to be a much more involved change that I expected. It\nstarted by adding syntax support for scientific notation (i.e. 32e5) but\nended up overhauling how numbers work in vsql, and solving some major\ncurrent and future problems.\n\nAll literals in scientific notation are considered `DOUBLE PRECISION`,\nthat part is pretty straightforward. Furthermore, all approximate\nnumbers are always formatted in scientific notation, even if smaller\nnumbers are given a \"e0\" suffix.\n\nSince this means that exact and approximate numbers now have a different\nform we can take a lot of hacky and unreliable guess work out of\nliterals and implicit casting.\n\n`REAL` and `DOUBLE PRECISION` no longer need to be treated as supertypes\nfor all other exact types. Which in retrospect makes no sense. The docs\nmake much more sense on how numbers work and this makes the larger\nchange of DECIMAL and NUMERIC types coming later much easier to explain\nand implement.","shortMessageHtmlLink":"language: Added approximate number literals"}},{"before":"c12ee81ca943b3e4bfe8052dd8b6a30358f37e78","after":"766a41a36dda4f33afa934c41786a89104af5d03","ref":"refs/heads/approximate-numeric-literal","pushedAt":"2023-12-23T21:03:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"language: Added approximate number literals\n\nThis turned out to be a much more involved change that I expected. It\nstarted by adding syntax support for scientific notation (i.e. 32e5) but\nended up overhauling how numbers work in vsql, and solving some major\ncurrent and future problems.\n\nAll literals in scientific notation are considered `DOUBLE PRECISION`,\nthat part is pretty straightforward. Furthermore, all approximate\nnumbers are always formatted in scientific notation, even if smaller\nnumbers are given a \"e0\" suffix.\n\nSince this means that exact and approximate numbers now have a different\nform we can take a lot of hacky and unreliable guess work out of\nliterals and implicit casting.\n\n`REAL` and `DOUBLE PRECISION` no longer need to be treated as supertypes\nfor all other exact types. Which in retrospect makes no sense. The docs\nmake much more sense on how numbers work and this makes the larger\nchange of DECIMAL and NUMERIC types coming later much easier to explain\nand implement.","shortMessageHtmlLink":"language: Added approximate number literals"}},{"before":"d47c4958ea5c49c916c581c5bebd6bea8436c43d","after":"c12ee81ca943b3e4bfe8052dd8b6a30358f37e78","ref":"refs/heads/approximate-numeric-literal","pushedAt":"2023-12-23T21:02:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"language: Added approximate number literals\n\nThis turned out to be a much more involved change that I expected. It\nstarted by adding syntax support for scientific notation (i.e. 32e5) but\nended up overhauling how numbers work in vsql, and solving some major\ncurrent and future problems.\n\nAll literals in scientific notation are considered `DOUBLE PRECISION`,\nthat part is pretty straightforward. Furthermore, all approximate\nnumbers are always formatted in scientific notation, even if smaller\nnumbers are given a \"e0\" suffix.\n\nSince this means that exact and approximate numbers now have a different\nform we can take a lot of hacky and unreliable guess work out of\nliterals and implicit casting.\n\n`REAL` and `DOUBLE PRECISION` no longer need to be treated as supertypes\nfor all other exact types. Which in retrospect makes no sense. The docs\nmake much more sense on how numbers work and this makes the larger\nchange of DECIMAL and NUMERIC types coming later much easier to explain\nand implement.","shortMessageHtmlLink":"language: Added approximate number literals"}},{"before":"b546e8e2587591dc5ed004e47467cbd2c7d8fa6c","after":null,"ref":"refs/heads/literals","pushedAt":"2023-12-23T16:40:16.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"}},{"before":"50beee4ae76f39bc7460c4eb18e8c5d66432f3fa","after":"1a22339166cd3f0f319bf3b0cd92239b4926814e","ref":"refs/heads/main","pushedAt":"2023-12-23T16:40:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"elliotchance","name":"Elliot Chance","path":"/elliotchance","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/927418?s=80&v=4"},"commit":{"message":"language: Integers now use the smallest exact type (#184)\n\n> ISO/IEC 9075-2:2016(E), 5.3 <literal>:\r\n> 22) The declared type of an <exact numeric literal> ENL is an\r\n> implementation-defined exact numeric type whose scale is the number of\r\n> <digit>s to the right of the <period>. There shall be an exact numeric\r\n> type capable of representing the value of ENL exactly.\r\n\r\nI misunderstood \"numeric\" to mean the NUMERIC type, but clearly they\r\nmean any exact numeric type (which includes SMALLINT, INTEGER and\r\nBIGINT).\r\n\r\nIntegers will now use the smallest type which makes casting up to\r\nsuper-types much more straight forward.\r\n\r\nAlso, SQL tests will not stop on the first failure making it much easier\r\nto cleanup multiple failing tests.","shortMessageHtmlLink":"language: Integers now use the smallest exact type (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2054834000\" data-permission-text=\"Title is private\" data-url=\"https://github.com/elliotchance/vsql/issues/184\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/elliotchance/vsql/pull/184/hovercard\" href=\"https://github.com/elliotchance/vsql/pull/184\">#184</a>)"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEOFRsBwA","startCursor":null,"endCursor":null}},"title":"Activity · elliotchance/vsql"}