Correct two values in the shared test data - #916
Open
phdoerfler wants to merge 2 commits into
Open
Conversation
Postgres's COPY block set NULL AS '', so the word null was a four-character string there and the CSV kept that spelling.
Oracle spelled it 'FALSE' and SQL Server 0 before the CSVs, and tagging the column brings both back.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As a follow-up to #912 I noticed two issues.
First, there is a boolean column which is currently not explicitly tagged as such but would benefit from it:
testdata/projection/level2.csv'sattr. So every dialect gets the string literal'false', where before #912 Oracle had'FALSE'and SQL Server had0. All three databases are fine with that and parse the boolean correctly. So far, that is. With the advent of SQLite this is no longer good enough: SQLite gives such a column INTEGER affinity and keeps'true'as text, reading it back as false. MySQL'sBOOLEANis aTINYINT(1), where'true'is an error under strict mode. Also,coalesce/cb.csvalready tags its boolean column.projectionwas the only one that did not.Second, before #912 the
unionsdataset held slightly different data on SQL Server and Oracle than on Postgres. Those two wrote a realNULLintocollections.itema/itemb, while Postgres'sCOPYblock setNULL AS '', so only an empty field became NULL there and the wordnullwas stored as a four-character string. #912 shared the Postgres spelling, which changed the value on the other two. Writing\Ngives all three a real NULL, which is what the fixture means: the row is not that variant of the union.This PR corrects both.
One more difference from before #912 turned up on the way: San Marino's
headofstatewas''on SQL Server, and NULL on Postgres and Oracle. It is NULL everywhere now.