Re: \gsetenv

From: David Fetter <david(at)fetter(dot)org>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: \gsetenv
Date: 2020-12-20 17:40:12
Message-ID: 20201220174011.GE13234@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 20, 2020 at 02:26:14PM +0100, Fabien COELHO wrote:
> Hello David,
>
> > We have \gset to set some parameters, but not ones in the environment,
> > so I fixed this with a new analogous command, \gsetenv. I considered
> > refactoring SetVariable to include environment variables, but for a
> > first cut, I just made a separate function and an extra if.
>
> My 0.02€: ISTM that you do not really need that, it can already be achieved
> with gset, so I would not bother to add a gsetenv.
>
> sh> psql
> SELECT 'Calvin' AS foo \gset
> \setenv FOO :foo
> \! echo $FOO
> Calvin

Thanks!

You're the second person who's mentioned this workaround, which goes
to a couple of points I tried to make earlier:

- This is not by any means a new capability, just a convenience, and
- In view of the fact that it's a very old capability, the idea that
it has implications for controlling access or other parts of the
space of threat models is pretty silly.

Having dispensed with the idea that there's a new attack surface here,
I'd like to request that people at least have a look at it as a
feature psql users might appreciate having. As the author, I obviously
see it that way, but again as the author, it's not for me to make that
call.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-12-20 18:07:12 Re: \gsetenv
Previous Message Andrew Dunstan 2020-12-20 17:09:59 Re: multi-install PostgresNode