`jdbc/execute!` unexpectedly qualifies column names that were explicitly unqualified using `SELECT ... AS ...`

[Dennis Schridde]

Describe the bug

jdbc/execute! unexpectedly qualifies column names that were explicitly unqualified using SELECT ... AS ....

To Reproduce

This HoneySQL:

(sql/format {:select [[[:encode :tab/one_field "hex"] :one]
                      [:tab/other_field :other]]
             :from   [:tab]})

Generates this SQL:

SELECT ENCODE(tab.one_field, "hex") AS one, tab.other_field AS other FROM tab

When I jdbc/execute! that, I get the following shape back:

[{:one "..." :tab/other "..."}]

Expected behavior

I explicitly renamed tab.other_field to other using AS, i.e. to something that was not qualified with the table name, so I would expect the map returned by next-jdbc to respect my choice.

I would expect tab.other_field to end up in the same way that tab.one_field does, which was also renamed using AS.

Environment (please complete the following information):

• OS: Linux
• Java Version: Red_Hat-17.0.8.0.7-1.fc38
• Clojure Version: 1.11.1
• Database: PostgreSQL 14.8
• Driver Library Version: org.postgresql/postgresql 42.6.0

[Sean Corfield]

The qualifiers are based on the table name that the JDBC driver provides for the columns. When you alias a column to a new name, several (most?) JDBC drivers retain the table name. When you alias a computed expression to a name, the drivers provide a blank table name, i.e., no qualifier. next.jdbc is just acting as a thin wrapper around JDBC here -- it only knows about what comes back from the driver, not what went into the database.