Re: \gsetenv

On Sun, Dec 20, 2020 at 11:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.