Excerpts from Michael Glaesemann's message of jue jul 05 11:36:51 -0400 2012:
>
> On Jul 5, 2012, at 11:17, Alvaro Herrera wrote:
> > However I am also against what seems to be the flow. Normally, you
> > don't write overloaded plpgsql functions such as "equal".
>
> I often write functions that perform fetches based on different criteria.
> For example,
>
> -- returns count of all orders for the given customer
> int function order_count(in_customer_name text)
>
> -- returns count of all orders for the given customer since the given timestamp
> int function order_count(in_customer_name text, in_since timestamp with time zone)
>
> -- returns count of orders for the given customer during a given interval
> int function order_count(in_customer_name text, in_from timestamp with time zone, in_through timestamp with time
zone)
Isn't this a perfect example of stuff that, since it does much the same
thing, should be in the same file so that you remember to fix them all
together if you find a bug in one?
> Or, I'll write overloaded functions, one of which provides default values.
>
> -- returns the set of members whose birthday is today. Calls birthday_members(CURRENT_DATE)
> setof record function birthday_members()
>
> -- returns the set of members whose birthday is on the given date, which makes testing a lot easier
> setof record function birthday_members(in_date DATE)
Same. This seems particularly the case if one implementation calls
another, more general one.
> Some may disagree that this is a "proper" usage of function overloading.
> Some may even argue that function names shouldn't be overloaded at all.
> However, I find this usage of function name overloading useful, especially
> for keeping function names relatively short.
I completely agree.
> If we're dumping objects (tables, views, functions, what-have-you) into separate files,
> each of these functions is a separate object and should be in its own file.
Clearly there is no consensus here.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support