On Fri, Mar 3, 2017 at 3:18 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > I'm ok with this patch. I think that the very simple automaton code > structure achieved is worth the very few code duplications. It is also > significantly shorter than the nested if/switch variants, and it does > exactly what Tom and Robert wished with respect to errors, so I think that > this is a good compromise.
I think that I have not taken a firm position on what the behavior should be with respect to errors. I took the position that the messages being printed saying what happened were too detailed, because they not only described what had happened but also tried to prognosticate what would happen next, which was dissimilar to what we do elsewhere and likely to be hard to maintain - or even get right for v1. 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. Other positions are also possible. I suggest that doing it the way Tom likes may be the path of least resistance, but this isn't really something I'm very animated about personally. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers