Hello Tom,
I also fear that there are corner cases where the behavior would still
be inconsistent. Consider
\if ...
\set foo `echo \endif should not appear here`
In this instance, ISTM that there is no problem. On "\if true", set is
executed, all is well. On "\if false", the whole line would be skipped
because the if-related commands are only expected on their own line, all
is well again. No problem.
AFAICS, you misunderstood the example completely, or else you're proposing
syntax restrictions that are even more bizarre and unintelligible than
I thought before.
Hmmm. The example you put forward does work as expected with the rule I
suggested. It does not prove that the rules are good or sane, I'm just
stating that the example would work consistently.
We cannot have a situation where the syntax rules for backslash commands
inside an \if are fundamentally different from what they are elsewhere;
Indeed, I do not see an issue with requiring some new backslash commands
to be on their own line: Any average programmer would put them like that
anyway for readability. What is the point of trying to write code to
handle strange unmaintainable oneliners?
that's just going to lead to confusion and bug reports.
Whatever is done, there will be some confusion and bug reports:-)
If someone writes a strange one-liner and see that it generates errors,
then the error messages should be clear enough. Maybe they will complain
and fill in bugs because they like backslash-command oneliners. That is
life.
Now you are the committer and Corey is the developer. I'm just a reviewer
trying to help. I can still review a larger patch which tries to be subtly
compatible with a lack of previous clear design by adding code complexity,
even if I think that this particular effort is a bad idea (i.e. mis-spent
resource on a useless sub-feature which makes future maintenance harder).
With some luck, Corey may find a way of doing it which is not too bad.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
