On Sat, Mar 11, 2017 at 9:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I thought the same of the version you were complaining about, but
> the current patch seems to have dialed it back a good deal. Do you
> still find the current error messages unmaintainable?
I haven't looked, but I had the impression this had been much improved.
>> But I have not taken a position on what should happen if the
>> condition for \if or \elsif evaluates to a baffling value. Corey's
>> prior proposal was to treat it, essentially, as neither true nor
>> false, skipping both arms of the if. Tom seems to want an invalid
>> value treated as false. You could also imagine pretending that the
>> command never happened at all, likely leading to complete chaos.
>
> Hmm, if that "prior proposal" was indeed on the table, I missed it.
> The current patch, AFAICS, implements your third choice, which I quite
> agree would lead to complete chaos; there would be no way to write a
> script that did anything useful with that.
Well, other than: don't write a script with invalid commands in it.
But I'm not seriously advocating for that position.
> It is interesting to think about what would happen if "expr is neither
> true nor false" were defined as "skip immediately to \endif" (which
> I think is the natural generalization of what you said to apply to an
> intermediate \elif). I believe that it'd be possible to work with it,
> but it's not very clear if it'd be easier or harder to work with than
> the rule of treating bogus results as false. What is clear is that
> it'd be unlike any other conditional construct I ever worked with.
True.
> As was pointed out upthread, "treat error results as false" is what
> you get from "if" in a POSIX shell. I think it's fair also to draw
> an analogy to what SQL does with null boolean values, which is to
> treat them as false when a decision is required (in, eg, WHERE or
> CASE). So I think "treat bogus results as false" is the most
> conservative, least likely to cause unhappy surprises, solution here.
I don't mind that. I was simply stating that I hadn't advocated for
anything in particular.
>> Other positions are also possible.
>
> If you've got concrete ideas about that, let's hear them. I'm not
> trying to foreclose discussion.
I personally don't, but others may.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company