Make stream more general

[johannesgerer]

Sometimes the setup of the state needs to know the number and potentially names of the columns. What do you think about this change?

[johannesgerer]

Polite bump...

Without this I currently have to maintain a fork to be able to access the internal module.

I would really appreciate it if this (or similar functionality) could be provided.

[johannesgerer]

Is there anything I can do to make this easier for you to accept/think about?

[spencerjanssen]

Disclaimer: I don't maintain this package, I'm just an interested party.

I think this is a good idea! I'm interested in using this in my employer's codebase. We have a home-grown class for deserializing [(Column, Value)] rows into domain types. Currently we validate the column names for every row in the result set. With this change we could instead validate the column names and count once per result set.

For the sake of backwards compatibility, perhaps we should instead introduce new streaming functions instead of changing the types of the existing ones?

[spencerjanssen]

Suggested change

	-> (state -> [(Column, Value)] -> m (Step state))
	-> (state -> [Value] -> m (Step state))

Given that state is now derived from our columns, does it make sense to remove Column here?

[chrisdone]

Disclaimer: I don't maintain this package, I'm just an interested party.

I think this is a good idea! I'm interested in using this in my employer's codebase. We have a home-grown class for deserializing [(Column, Value)] rows into domain types. Currently we validate the column names for every row in the result set. With this change we could instead validate the column names and count once per result set.

For the sake of backwards compatibility, perhaps we should instead introduce new streaming functions instead of changing the types of the existing ones?

I agree on introducing new ones with new names. Otherwise the changes sound good.