Implement NextResultSet in a way compatible with sql.Rows.NextResultSet()

[kmpm]

Is your feature request related to a problem? Please describe. When trying to use pgx in a multi database module, like scany or similar, and trying to be compatible with database/sql it fails because NextResultSet like in sql.Rows is not implemented. Also see https://github.com/jackc/pgx/issues/308 and https://github.com/jackc/pgx/issues/1512 Yes I know you "shouldn't" use NextResultSet and I really don't like it but I proprietary system I have to live with returns multiple result sets and that isn't something I can change.

Describe the solution you'd like Even if it's slow and not optimal, perhaps it's possible to emulate it using MultiResultReader or something. I'd gladly help but I do not have detailed enough knowledge about pgx to figure out if it's even possible.

Describe alternatives you've considered Just implement the function and always return false for now.

Additional context

[jackc]

I'm not sure I understand. Are you actually expecting multiple result sets from a single PostgreSQL query or is some library just expecting the interface to be implemented?

For the former, the only way I know to do that is to use the simple protocol and bundle concatenate the SQL statements together. If this is the case it should be possible for stdlib to be modified to use MultiResultReader to support this case though I don't know how much work it would be.

If it's just expecting the interface, I would have expected either database/sql or the other library to check for support due to only certain driver/database combinations usefully supporting it.

[nathanjcochran]

I also think it would be great if the stdlib package implemented the driver.RowsNextResultSet interface.

Are you actually expecting multiple result sets from a single PostgreSQL query or is some library just expecting the interface to be implemented?

In my case, it's the former. Our use case is building a SQL editor, where users can input arbitrary SQL and click "Run". If they enter multiple statements, we want to return a result set for each statement. But we don't know ahead of time how many statements they've entered, and we'd rather avoid implementing our own parser to split the SQL into separate statements that get run individually (or via the current batch interface).

Additionally, because our SQL editor supports multiple different database types, it would be great if we could rely on the database/sql standard library for executing queries instead of dropping down to the lower-level pgx packages, so that our interface for querying is consistent across database types 😅.

[kmpm]

Sorry for the late reply but my use case is similar to @nathanjcochran.