Re: PSQL commands: \quit_if, \quit_unless
От | Fabien COELHO |
---|---|
Тема | Re: PSQL commands: \quit_if, \quit_unless |
Дата | |
Msg-id | alpine.DEB.2.20.1612061401310.16863@lancre обсуждение исходный текст |
Ответ на | Re: PSQL commands: \quit_if, \quit_unless (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: PSQL commands: \quit_if, \quit_unless
|
Список | pgsql-hackers |
Hello Robert, >> Your experience as an seasoned core developer and a committer is >> probably different:-) > > Well, everybody can have their own opinion on what is reasonable. Sure. > There are times I argue for making a patch smaller (frequent) and > times when I argue for making it bigger (rare). Yep. > We had pretty much this exact same argument about the pgbench lexer and > parser and in the event I coded something up in less than a day. This > argument feels like a rerun of that one. There are some differences: pgbench already had one operator at a time expressions, while psql has survived till today with none, which suggest a less pressing need. Moreover the features are partly orthogonal and would touch psql significantly in different although probably overlapping areas: - expressions is rather about \set, even if reused with \ifas well - condition is about \if ... \endif and ignoring some input lines The current expression evaluation in pgbench is about 1000 lines for scanning, parsing & evaluating, and does not yet support boolean expressions, although a patch for that has been in the queue for some time. I foresee that someone will suggest/require/demand... that the expression code be shared between pgbench and psql, which is another argument for dissociating these two features (expression and conditional in psql) from the start. -- Fabien.
В списке pgsql-hackers по дате отправления: