## Pavel Stehule (pavel.steh...@gmail.com):
> it is not consistent with other \g* commands. Maybe a new statement \senv
> ? But what is the use case? You can just press ^z and inside shell write
> echo $xxx, and then fg
That does not work: backgrounding psql will put you into your original
On 12/28/21 14:53, Tom Lane wrote:
> Matheus Alcantara writes:
>>> it is not consistent with other \g* commands. Maybe a new statement \senv ?
>>> But what is the use case? You can just press ^z and inside shell write echo
>>> $xxx, and then fg
>> I think that the basic use case would be just
On Tuesday, December 28th, 2021 at 16:53, Tom lane...@sss.pgh.pa.us wrote:
> Matheus Alcantara msalcantara@pm.me writes:
>
>>> it is not consistent with other \g* commands. Maybe a new statement \senv ?
>>> But what is the use case? You can just press ^z and inside shell write echo
>>>
Matheus Alcantara writes:
>> it is not consistent with other \g* commands. Maybe a new statement \senv ?
>> But what is the use case? You can just press ^z and inside shell write echo
>> $xxx, and then fg
> I think that the basic use case would be just for debugging, instead call
> \getenv
> út 28. 12. 2021 v 19:51 odesílatel Matheus Alcantara
> napsal:
>
>> Hi pgsql hackers, I was testing the new psql command \getenv introduced on
>> commit 33d3eeadb2 and from a user perspective, I think that would be nice if
>> the PSQLVAR parameter were optional, therefore when it is only
út 28. 12. 2021 v 19:51 odesílatel Matheus Alcantara
napsal:
> Hi pgsql hackers, I was testing the new psql command \getenv introduced on
> commit 33d3eeadb2 and from a user perspective, I think that would be nice
> if the PSQLVAR parameter were optional, therefore when it is only necessary
> to
