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 \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.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
