Hello Corey,
I wished for the same thing, happy to use one if it is made known to me.
I pulled that pattern from somewhere else in the code, and given that the
max number of args for a command is around 4, I'm not too worried about
scaling.
If there are expressions one day like pgbench, the number of arguments
becomes arbitrary. Have you looked at PQExpBuffer?
However there is an impact on testing because of all these changes. ISTM
that test cases should reflect this situation and test that \cd, \edit, ...
are indeed ignored properly and taking account there expected args...
I think one grand
\if false
\a
\c some_connect_string
...
\z some_table_name
\endif
should do the trick,
Yes. Maybe some commands could be on the same line as well.
but it wouldn't detect memory leaks.
No miracle...
There seems to be pattern repetition for _ev _ef and _sf _sv. Would it
make sense to create a function instead of keeping the initial copy-paste?
Yes, and a few things like that, but I wanted this patch to keep as much
code as-is as possible.
If you put the generic function at the same place, one would be more or
less kept and the other would be just removed?
"git diff --patience -w" gives a rather convenient output for looking at
the patch.
I would suggest to put together all if-related backslash command, so that
the stack management is all in one function instead of 4.
I recognize the urge to group them together, but would there be any actual
code sharing between them? Wouldn't I be either re-checking the string
"cmd" again, or otherwise setting an enum that I immediately re-check
inside the all_branching_commands() function?
I do not see that as a significant issue, especially compared to the
benefit of having the automaton transition management in a single place.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
