If we could draw a line between "safe" and "unsafe" environment
variables, I'd be willing to consider a patch that allows directly
setting only the former. But I don't see how to draw that line.
IIUC the threat here is for users that write:
SELECT * FROM view \gset
Because if you are writing
SELECT col1, col2, col3 OR SELECT expression AS col1 \gset
The query author has explicitly stated which variable names they exactly want to change/create and nothing the server can do will be able to alter those names.
Or *is* that the problem - the server might decide to send back a column named "breakme1" in the first column position even though the user aliased the column name as "col1"?
Would a "\gsetenv (col1, col2, col3, skip, col4)" be acceptable that leaves the name locally defined while relying on column position to match?
How much do we want to handicap a useful feature because someone can use it alongside "SELECT *"? Can we prevent it from working in such a case outright - force an explicit column name list at minimum, and ideally aliases for expressions? I suspect not, too much of that has to happen on the server. That makes doing this by column position and defining the names strictly locally a compromise worth considering. At worst, there is no way to get an unwanted variable to appear on the client even if the data for wanted variables is made bogus by the compromised server. I don't see how avoiding the bogus data problem is even possible.
David J.