>> Yes. Anything as simple as this might fail: >> SELECT ? FROM RDB$DATABASE >> SELECT ? + ? FROM RDB$DATABASE > > Confirmed: This is unsupported. > AFAIK even oracle doesn't support binding to the "column name" like this, > although it looks like the query is just returning constants.
At least any of these databases support such queries (type is inferred and/or coerced at bind time or at fetch time): - Ingres (with some flaws) - MySQL - Postgres - Oracle - SQL Server - SQLite - Sybase SQL Anywhere (with some flaws) Type inferring and coercion is a matter of philosophy. Some databases are quite lenient with this. > I *really* need to start reading deeper into the jooq source to see why we > need these types of query... Why? "It can be done with SQL? -> It can be done with jOOQ." :-) These are just simple examples. I can imagine more complex ones that are more likely to appear in real-life situations. > Ouch. You're completely correct: this query will not execute. > Apparently there's a hard limit of 64KB per row, excluding BLOBs. > The limit seems to also extends to SELECT resultset rows, which is kinda > weird, but i suppose it is what it is. Crazy, eh? See the remark on the LPAD() function: http://www.firebirdsql.org/refdocs/langrefupd21-intfunc-lpad.html "With (VAR)CHARs, it is generally wise to CAST the result to a smaller size. The default result length of 32765 may, in combination with other output columns, lead to a “block size exceeds implementation restriction” error." That's a nice way of delegating a serious implementation problem to client code... "generally wise", whatever ;-) > Is this a showstopper issue? It is nasty, indeed. Right now, I'm trying to cast all varchar bind values to VARCHAR(4000), which is the max size supported by Oracle. For the integration tests, that seems to be fine so far, but there will be other corner cases, of course. But I don't think it's a show stopper for jOOQ. As for deciding about productive databases, I don't know... Cheers Lukas
