Alvaro Herrera wrote:
>>Tom Lane wrote:
>>What I see is that the overloading is a very cool feature, but is not
>>necessary in most cases, and it introduces unnecessary administration
>>hassles.
> What are those unnecessary administration hassles? I'm not seeing what
> could be so bad as to merit the added code complexity. Maybe the
> problem is just that you are not using the appropiate administration
> tool?
Functions are not the same as stored procedures, but since PG lacks
stored procedures, there is a necessity to use functions instead.
Stored procedures (in the RDBMSs that support them) are normally used to
1) run batch processes, and 2) separate the interface from the
database logic (by interface, I mean an interface with the client app).
Functions on the other side are very convenient as a kind of
parameterisable or extended view, and (if there are stored procedures
available) not really intended as an interface with the front-end.
One of the first hassles with using functions as an interface (mainly
with web-based) front-ends is that, despite de fact that you'd normally
never (or very rarely) use or require overloading, you're still required
to cast every parameter to match that of the function. And when you
have, say, 50 parameters (used by a web form to create, for instance, a
customer, with information spread around many tables), if you miss
casting the type on one of them (e.g. to int2 if that's the way it's
been defined) you get an error.
Another is that if you cannot use CREATE OR REPLACE to change one of the
parameters, thus having to drop and recreate, and this requires setting
all the permissions all over again.
Another one would be the impossibility to implement parameter defaults,
and the chance to provide some of the values in a different order than
that of the function's definition, by specifying the parameter names (a
feature already present in the TODO list) and letting the function use
the defaults for the missing parameters.
Anyway, this is not about being annoying, I think it would be great if
PG had not only its own special and unique features, but also all the
common features you would find in other RDBMSs, for portability and
convenience.
Cheers,
Ezequiel Tolnay
