On Sat, Mar 11, 2017 at 9:40 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers