Re: Wishlist?
От | Ezequiel Tolnay |
---|---|
Тема | Re: Wishlist? |
Дата | |
Msg-id | dc1ffp$ssn$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: Wishlist? (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Wishlist?
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: