go-sqlite3 icon indicating copy to clipboard operation
go-sqlite3 copied to clipboard

use sqlite3_column_type() for ColumnTypeScanType()

Open alkemir opened this issue 9 months ago • 3 comments

The current implementation was changed in PR-909 stating that sqlite3_column_type() always returns SQLITE_NULL, but as noted in ISSUE-600, the case was probably because for SQLite3, sqlite3_column_type() must be called after calling Next(). sqlite3_column_type() returns the types for the columns on a given row, thus the cursor must be pointing to a valid row. See SQLite docs on API lifecycle, rows and columns methods and this forum post

The Go API does not restrain the behavior of RowsColumnTypeScanType() as to when it should be called. Thus, the implementation in this PR makes a compromise and falls back to sqlite3_column_decltype() in a best effort to remain retro-compatible, but this is still a potentially breaking change.

The advantage of using sqlite3_column_type() over sqlite3_column_decltype() is two-fold:

  1. It is closer to the SQLite3 API
  2. It will return the correct scanType for expressions and aggregate functions, which are the cases in which sqlite3_column_decltype() is insufficient. Regarding this aspect, the existing implementation provides no way to access the values without potentially triggering a type conversion, unless the application is aware of the result type of the query beforehand.

alkemir avatar Mar 17 '25 02:03 alkemir

Please add a unit test for the new behavior.

rittneje avatar Mar 21 '25 11:03 rittneje

Should we still return the nullable types? When SQLite returns a NULL value, the column type will be type_any, so there is no need for nullable types now.

alkemir avatar Mar 24 '25 00:03 alkemir

Thank you for all the reviews, is there anything else that I can do to improve this PR?

alkemir avatar Apr 12 '25 19:04 alkemir