On Jul 5, 2012, at 11:17, Alvaro Herrera wrote: > > Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012: >> Joel Jacobson <j...@trustly.com> writes: >>> Maybe it could be made an option to pg_dump? >> >> Ick. Then we have to deal with all the downsides of *both* methods. >> >> pg_dump is already a bloated, nearly unmaintainable mess. The very >> last thing it needs is even more options. > > Agreed. > > 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) 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) 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. 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. Michael Glaesemann grzm seespotcode net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
