feat: standardization/unification for Query

[flymedllva]

Feature Request

I want to write a wrapper package that uses Execute/ReadRow/ReadResultSet from Session and TxActor, encountered that the signature of the methods became very different

1. options package is imported from internal, so I cannot describe a partial interface consisting of 1 method.
2. for Session & TxActoroptions have become different – ExecuteOption & TxExecuteOption, which prevents you from using 1 interface for them
3. I don't like the fact that the Execute call in Session gives Transaction, because of this method signature is different from TxActor, which does not allow to use 1 interface, as I used to do with database/sql. That said, I understand the idea of needing to return Transaction, but maybe in TxActor, it should also be returned?

[asmyasnikov]

Some options for query session Execute not aplliable to transaction Execute For example: query session Execute allowed option tx control for define isolation level on start transaction and auto-commit flag, but transaction already opened early and tx control is wrong option Thats why options are different for session and transaction Execute. But each option both allowed (session and transaction Execute) have a concrete type which compatible with options.ExecuteOption and options.TxExecuteOption

[flymedllva]

Some options for query session Execute not aplliable to transaction Execute For example: query session Execute allowed option tx control for define isolation level on start transaction and auto-commit flag, but transaction already opened early and tx control is wrong option Thats why options are different for session and transaction Execute.

Yes, that's understandable, but would like to understand this as a developer, while having a unified interface to be honest

But each option both allowed (session and transaction Execute) have a concrete type which compatible with options.ExecuteOption and options.TxExecuteOption

Having said that, the options are the same in Table(), yes you can see the difference in TransactionControl, but as a developer I would rather have the default behavior and have the options override this only for transaction start.

I realize the idea was to give accurate state management tools, but compared to sql/database && pgx it's awkward, they have very similar interfaces with and without transaction.

[flymedllva]

What's the answer to that question?

1. options package is imported from internal, so I cannot describe a partial interface consisting of 1 method.

[asmyasnikov]

Having said that, the options are the same in Table(), yes you can see the difference in TransactionControl, but as a developer I would rather have the default behavior and have the options override this only for transaction start.

In Table service I made some design issues, which I tried to fix in Query service

[flymedllva]

I really don't understand how to use these closed structs/interfaces. Let's say I want to pass params.Builder from function to function, I can't do it, because it is from the package ../internal/params.

I would also like to be able to create parameters from types, say using table/types and then putting them into params.

This is the most awkward golang api I've ever used. That's probably what you wanted, but I don't understand how to work with it