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


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,

> 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 ;
  select 1;

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.

Reply via email to