support int2vector and oidvector types#2408
Conversation
|
Footnotes
|
int2vector and oidvector types
There was a problem hiding this comment.
We definitely need more tests of these types being used in normal tables, so we should add tests to testing/go/types_test.go.
We should also add binary wire compatibility for these types, which is in server/wire_format.go. The accompanying wire format tests are in testing/go/wire_test.go.
Writing wire tests is fairly straightforward as these won't be any different than the majority of the other tests. The setup script just declares and populates a table with the desired types. Then we have two assertions:
- Send a
Parsemessage with the query and any name - Send a
Describemessage for the name given inParse - Send a
Syncmessage to end the messages
Then Receive should match whatever Postgres returns (I'll go over this at the end). For the second assertion, it's a little different:
- Send a
Bindmessage with the same name as earlier. However, we setResultFormatCodesto0to test for the text wire format, and1for the binary wire format. There should be two tests to account for the two return types. - Send the
Executemessage - Send the
Closemessage - Send the
Syncmessage
As before, Receive should contain whatever Postgres returns back. In order to easily get the Postgres values, set the ExternalServerPort field to whatever port your local Postgres instance runs at. You'll need a default Postgres user with the default password of password for it to work. Then you just modify the Receive messages until the tests pass for Postgres, and now you have your ground-truth for what the Doltgres return values should be. According to some external project documents, it looks like both int2vector and oidvector should behave identically to their array counterparts for binary output, but of course this has to be verified with the wire results from Postgres directly (these docs are sometimes wrong since they're not official Postgres docs). Easiest way to achieve that would be to simply pass the value back into writeBinaryWireData except change the type to the array equivalent. Not sure how the array of vectors should work though, so you'll have to reverse engineer that.
No description provided.