Re: two-argument aggregates and SQL 2003 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: two-argument aggregates and SQL 2003
Date
Msg-id 11231.1145035066@sss.pgh.pa.us
Whole thread Raw
In response to Re: two-argument aggregates and SQL 2003  ("Sergey E. Koposov" <math@sai.msu.ru>)
Responses Re: two-argument aggregates and SQL 2003  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Sergey E. Koposov" <math@sai.msu.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Practical impediment to supporting multiple SSL libraries
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Practical impediment to supporting multiple SSL libraries