Re: Schema version management
От | Alvaro Herrera |
---|---|
Тема | Re: Schema version management |
Дата | |
Msg-id | 1341503223-sup-3698@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Schema version management (Michael Glaesemann <grzm@seespotcode.net>) |
Ответы |
Re: Schema version management
Re: Schema version management |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: