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.


There are times I argue for making a patch smaller (frequent) and
times when I argue for making it bigger (rare).


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 \if as 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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to