I was just suggesting a tiny new test that shows that a text or int value can be read as a Stream, nothing more. I wouldn't touch this test - it's a complicated one that tests SequentialAccess behavior as well, etc.

Complex tests aren't good tests in terms of unit testing. So this one just tests for an exceptions, while the existing does all other things as before. Moreover, it should be expanded to cover other types too, but a bit later (:

I agree that this test is a bit overly-complicated (because it tests multiple things). I just wouldn't touch it as part of this PR :)

Do you mean that these lines of code should be returned to GetStream?

Sorry, I misunderstood your changes - now it's clearer. The splitting up of the complex test is a good thing.

But taking a closer look at the previous test, it tested more than what is being tested here, no? Your new test makes sure that you can't get a stream if another stream is already open on the column. The previous version checked other stuff too - that going back inside the column fails for SequentialAccess, but is OK otherwise.

Just to make sure it's intentional: this doesn't create an array of 1024 consecutive byte values, but rather an array of 4096 byte values which represent 4-byte int data... Is there any reason? It's usually easier when debugging tests to have simple consecutive data, in order to understand what's going on.

Previously there was a comment containing a to-do. The idea was to test sequential mode truly, but for this we should have more data than the buffer could contain. So multiply 4096 by 2 and add some extra from the PostgreSQL protocol.

Sorry, I misunderstood your changes - now it's clearer. The splitting up of the complex test is a good thing.

But taking a closer look at the previous test, it tested more than what is being tested here, no? Your new test makes sure that you can't get a stream if another stream is already open on the column. The previous version checked other stuff too - that going back inside the column fails for SequentialAccess, but is OK otherwise.