-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default SQL data type for character values #102
Comments
I'm pretty sure the default should be TEXT |
SQLite doesn't support VARCHAR(n), but it will gloss over it. So why not default to VARCHAR(n) since that will work in both MySQL and PostgreSQL? |
@hannesmuehleisen: How many DBMS actually support this? MySQL and PostgreSQL don't. (There seems to be a newer standard (2011), I doubt that much has changed there.) TEXT is supported by SQLite, MySQL, and PostgreSQL, but not by SQL Server. I'll play it safe and keep it simple here -- return "TEXT". |
- Interface changes - `dbDataType()` maps `character` values to `"TEXT"` by default (#102). - The default implementation of `dbQuoteString()` doesn't call `encodeString()` anymore: Neither SQLite nor Postgres understand e.g. `\n` in a string literal, and all of SQLite, Postgres, and MySQL accept an embedded newline (#121). - Interface enhancements - New `dbSendStatement()` generic, forwards to `dbSendQuery()` by default (#20, #132). - New `dbExecute()`, calls `dbSendStatement()` by default (#109, @bborgesr). - New `dbWithTransaction()` that calls `dbBegin()` and `dbCommit()`, and `dbRollback()` on failure (#110, @bborgesr). - New `dbBreak()` function which allows aborting from within `dbWithTransaction()` (#115, #133). - Export `dbFetch()` and `dbQuoteString()` methods. - Documentation improvements: - One example per function (except functions scheduled for deprecation) (#67). - Consistent layout and identifier naming. - Better documentation of generics by adding links to the class and related generics in the "See also" section under "Other DBI... generics" (#130). S4 documentation is directed to a hidden page to unclutter documentation index (#59). - Fix two minor vignette typos (#124, @mdsumner). - Add package documentation. - Remove misleading parts in `dbConnect()` documentation (#118). - Remove misleading link in `dbDataType()` documentation. - Remove full stop from documentation titles. - New help topic "DBIspec" that contains the full DBI specification (currently work in progress) (#129). - HTML documentation generated by `staticdocs` is now uploaded to http://rstats-db.github.io/DBI for each build of the "production" branch (#131). - Further minor changes and fixes. - Internal - Use `contains` argument instead of `representation()` to denote base classes (#93). - Remove redundant declaration of transaction methods (#110, @bborgesr).
I don't think If you are worried about new data not fitting into a varchar_data_type <- function(x) {
size <- 2L^(floor(log2(max(nchar(as.character(x))))) + 1L)
paste0("VARCHAR(", size, ")")
}
varchar_data_type("t")
#> [1] "VARCHAR(2)"
varchar_data_type("te")
#> [1] "VARCHAR(4)"
varchar_data_type("test")
#> [1] "VARCHAR(8)" |
@jimhester: This is only the fallback, DBI drivers are free to override. I think it will be difficult to find a solution that works in all cases, so |
I agree it is difficult to find a good default, but I think the default should at least be part of the SQL 92 specification, this is explicitly mentioned in
Probably the most compatible solution would be just to use I agree this default is not terribly important because drivers can define their own method, but |
https://github.com/rstats-db/DBI/pull/97/files/c4a8b60bf4b9d4661838af135a24c7f31590ddd5#r61682461
What is the most sensible default here?
CC @hadley @hannesmuehleisen
The text was updated successfully, but these errors were encountered: