Re: \gsetenv
От | Andrew Dunstan |
---|---|
Тема | Re: \gsetenv |
Дата | |
Msg-id | cfed2af6-b1f9-a349-bbf7-57489b162696@dunslane.net обсуждение исходный текст |
Ответ на | Re: \gsetenv (David Fetter <david@fetter.org>) |
Список | pgsql-hackers |
On 12/16/20 10:54 PM, David Fetter wrote: > >> Besides which, you haven't bothered with even one word of positive >> justification. What's the non-hazardous use case? > Thanks for asking, and my apologies for not including it. > > I ran into a situation where we sometimes got a very heavily loaded > and also well-protected PostgreSQL server. At times, just getting a > shell on it could take a few tries. To mitigate situations like that, > I used a method that's a long way from new, abstruse, or secret: have > psql open in a long-lasting tmux or screen session. It could both > access the database at a time when getting a new connection would be > somewhere between difficult and impossible. The bit that's unlikely > to be new was when I noticed that it could also shell out > and send information off to other places, but only when I put together > a pretty baroque procedure that involved using combinations of \gset, > \o, and \!. All of the same things \gsetenv could do were doable with > those, just less convenient, so I drafted up a patch in the hope that > fewer others would find themselves jumping through the hoops I did to > get that set up. Does this help? andrew=# select 'abc'::text as foo \gset andrew=# \setenv FOO :foo andrew=# \! echo $FOO abc andrew=# cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: