> > > 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.
