evaluate behavior of adding a tuple_() as a column to select(), Query(). coerce? behavior changes on master?

Issue

When trying to select a tuple_:

class User(base):
  __tablename__ = "users"
  uid = Column(Integer, primary_key=True)
  username = Column(String)

[...]

q = session.query(User).add_columns(sqlalchemy.tuple_(User.uid, User.username))
print(q.all())

The returned value for the tuple is a string, which is hardly exploitable: [(<__main__.User object at 0x7fa37c9fce48>, '(1,foo)')]

One requires, I think, with a postgresql backend to test this.

Expected behavior

I would expect to receive a Python tuple [(<__main__.User object at 0x7fa37c9fce48>, (1, 'foo'))] as a result.

Versions

Flask-SQLAlchemy==2.4.0

[zzzeek]

this should work on 1.3.x and 1.2.x:

from sqlalchemy.orm.query import _BundleEntity

def add_bundle(bundle):
    def process(q):
        q = q._clone()
        q._entities = list(q._entities)
        _BundleEntity(q, bundle)
        q._set_entity_selectables(q._entities[-1:])
        return q

    return process


q = session.query(User).with_transformation(
    add_bundle(Bundle("mybundle", User.uid, User.username))
)
print(q.all())

[zzzeek]

since no backend other than PostgreSQL actually allows the syntax of “SELECT (x, y, z) FROM table”, I’ve opted to go with a compile-level raise when the tuple is detected as being placed in the top-most columns clause of the statement. the Bundle implies a non-tuple series of columns in the SELECT that become a sub-row. It’s different and it would be best if, given a tuple_() in the select(), we refuse the temptation to guess.