Re: two-argument aggregates and SQL 2003

"Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> writes:
> Does it make sense to extend the aggregate
> functions to the only two-argument case?

No, I don't think so, for two reasons:

1. The user's-eye view: if someone wants 2 arguments, tomorrow he'll
want 3, etc. There's an old saying that "the only good numbers in
programming language design are zero, one, and N" --- if you allow more
than one of anything, there shouldn't be an upper limit on how many you
allow. In practice there are many places in PG where we break that rule
to the extent of having a configurable upper limit (eg MAX_INDEX_KEYS)
... but small limits hard-wired into the code are just not pleasant.

2. The implementor's view: hard-wired limits are usually not that nice
from a coding standpoint either. Polya's Inventors' Paradox states that
"the more general problem may be easier to solve", and I've found that
usually holds up in program design too. Code that handles exactly 2 of
something is generally uglier and less maintainable than code that
handles N of something, because for example you are tempted to duplicate
chunks of code instead of turning them into loops.

regards, tom lane