Re: \gsetenv

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: \gsetenv
Date: 2020-12-17 15:37:11
Message-ID: cfed2af6-b1f9-a349-bbf7-57489b162696@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-12-17 15:42:10 Re: Optimizing the documentation
Previous Message Laurenz Albe 2020-12-17 15:16:52 Re: allow to \dtS+ pg_toast.*