Dunno, that sounds a lot like an "if the only tool I have is a hammer, then this must be a nail" argument.
More of a "don't rock the boat more than absolutely necessary", but knowing that adding another global struct might be welcomed is good to know.
reasonable interpretation of what it's for. Inventing a PsqlFileState or similar struct might be a good idea to help pull some of that cruft out of pset and get it back to having a reasonably clearly defined purpose of holding "current settings".
+1
command was ignored" warning messages). I'm failing to follow why
GetVariable would need to care.
It took me a second to find the post, written by Daniel Verite on Jan 26, quoting:
> Revised patch
A comment about control flow and variables:
in branches that are not taken, variables are expanded
nonetheless, in a way that can be surprising.
Case in point:
\set var 'ab''cd'
-- select :var;
\if false
select :var ;
\else
select 1;
\endif
The 2nd reference to :var has a quoting hazard, but since it's within
an "\if false" branch, at a glance it seems like this script might work.
In fact it barfs with:
psql:script.sql:0: found EOF before closing \endif(s)
AFAICS what happens is that :var gets injected and starts a
runaway string, so that as far as the parser is concerned
the \else ..\endif block slips into the untaken branch, as a part of
that unfinished string.
So that was the reasoning behind requiring GetVariable to know whether or not the statement was being ignored.