Robert Haas <robertmh...@gmail.com> writes:
> Given the precedent in pgbench (cf.
> 878fdcb843e087cc1cdeadc987d6ef55202ddd04), I think it requires an
> amazing level of optimism to suppose we won't eventually end up with a
> full-blown expression language here. I would suggest designing one
> from the beginning and getting it over with. Even if you manage to
> hold the line and exclude it from whatever gets committed initially,
> somebody's going to propose it 2 years from now. And again 4 years
> from now. And again 2 years after that.
The other problem with not thinking about that general case is that
people will keep on proposing little bitty features that nibble at
the problem but may or may not be compatible with a general solution.
To the extent that such patches get accepted, we'll be forced into
either backwards-compatibility breakage or sub-optimal solutions when
we do get to the point of wanting a general answer. I'd much rather
start with a generalized design and then implement it piece by piece.
(This is more or less the same point as my nearby stand against localized
hacking of backslash parsing rules.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
