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 <joel@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