The past, present, and future of two women and a girl.
Basically, Miya has basically had two mothers ever since she was
young, going with her mother to her mother’s friend Koyomi for meals.
And now a teenager, Miya realizes what Koyomi feels for her mother may
be more than just friendship.
The author, Harumi Chihiro, is quite good at these little dramas.
Some other excellent choices from her include 彼岸 (Higan,
or “Nirvana”) and カノン (Canon).
JDBC lets you get the types of the parameters of a prepared statement, and the types of the result set, without actually executing the statement.
That also works when you have bind parameters.
But in this SQL statement, what are the types of the result set columns?
The parameter could be literally anything! Even in this statement:
the types of the parameter and the result are arguably ambiguous (what if the parameter is NUMERIC? or DOUBLE PRECISION?).
It turns out the PostgreSQL JDBC driver, at least, just makes its best guess:
Here you can see that PostgreSQL has just filled in “text” as its best guess as to the type.
But of course, if you bound an integer, you’d get back an integer.
If you did have the actual parameter values, could you get the actual types of the result set columns, taking those parameter values into account?
It turns out, yes, at least for the PostgreSQL JDBC driver!
Just bind them and call getMetaData again:
error: Expression of type "StatusCode" cannot be assigned to declared type "Literal[StatusCode.ALREADY_EXISTS]"
"StatusCode" cannot be assigned to type "Literal[StatusCode.ALREADY_EXISTS]" (reportGeneralTypeIssues)
The solution is to just delete the annotation. pyright will infer the right type, as you can see with reveal_type():
importenumclassStatusCode(enum.IntEnum):ALREADY_EXISTS=...reveal_type(AdbcStatusCode.ALREADY_EXISTS)# information: Type of "StatusCode.ALREADY_EXISTS" is "Literal[StatusCode.ALREADY_EXISTS]"
clang-tidy might complain it can’t find headers that it should be able to find as a matter of course:
c/driver/postgresql/connection.h:20:10: error: 'cstdint' file not found [clang-diagnostic-error]
It turns out that clang-tidy needs to be able to resolve where the compiler looks for these standard headers, and if the compiler used is a symlink, it won’t find them.
Details are in llvm/llvm-project#46804.
To fix it, use a compile_commands.json (e.g. for CMake, set CMAKE_EXPORT_COMPILE_COMMANDS=ON) and make sure that CC and CXX point to the actual compilers, not a symlink: