Merge lp:~mmcm/akiban-server/sql-more-types into lp:~akiban-technologies/akiban-server/trunk
Status: | Merged |
---|---|
Approved by: | Mike McMahon |
Approved revision: | 2646 |
Merged at revision: | 2644 |
Proposed branch: | lp:~mmcm/akiban-server/sql-more-types |
Merge into: | lp:~akiban-technologies/akiban-server/trunk |
Diff against target: |
60 lines (+13/-12) 2 files modified
src/main/java/com/akiban/sql/aisddl/TableDDL.java (+7/-4) src/test/resources/com/akiban/sql/pg/yaml/functional/test-create-table.yaml (+6/-8) |
To merge this branch: | bzr merge lp:~mmcm/akiban-server/sql-more-types |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Akiban Build User | Needs Fixing | ||
Nathan Williams | Approve | ||
Mike McMahon | Needs Resubmitting | ||
Review via email: mp+161007@code.launchpad.net |
Description of the change
Server side for parsing more types.
Most notable for actual users is that TEXT is now allowed in DDL and not just in higher-level layers.
Also includes the MySQL sized types, because they are known to the AIS, so this is mostly harmless.
The remaining exceptional types are:
* TIMESTAMP. As far as I know, we do not implement MySQL TIMESTAMP semantics on INSERT/UPDATE, even though we track the type for replication. So, TIMESTAMP on CREATE TABLE turns into DATETIME. We do not want to sacrifice the TIMESTAMP keyword (which is standard SQL for an instance within a day). So, if we did implement the semantics, we'd need a new name like MYSQL_TIMESTAMP.
* FLOAT. This will load as DOUBLE, because FLOAT in Derby takes precision. So, it needs to dump as REAL, thereby preserving the semantics at the expense of not having the same syntax.
* BLOB. This turns into LONGBLOB on load. Not that we care, but that better represents to the adapter what we want that standard type to be. So, a MySQL BLOB will load larger than it was if dumped and restored through PSQL.
I think these are reasonable tradeoffs, but I could be persuaded to take a different approach.
Your tradeoffs make sense to me.
There's a workaround TODO on TableDDL.java#285. Can that be removed after your associated parser change?
Looks fine otherwise.