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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
