Re: Drop all overloads of a function without knowing parameter types
От | Tom Lane |
---|---|
Тема | Re: Drop all overloads of a function without knowing parameter types |
Дата | |
Msg-id | 14464.1391532518@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Drop all overloads of a function without knowing parameter types (Sergey Konoplev <gray.ru@gmail.com>) |
Ответы |
Re: Drop all overloads of a function without knowing parameter
types
Re: Drop all overloads of a function without knowing parameter types |
Список | pgsql-general |
Sergey Konoplev <gray.ru@gmail.com> writes: > On Tue, Feb 4, 2014 at 8:35 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> Sergey Konoplev escribi�: >>> On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> People periodically ask for extensions flavored more or less like this, >>>> but I'm suspicious of building any such thing into the core. There's too >>>> little commonality in the exact conditions they want to search on. >>>> Leaving it at the level of a scripting problem, as above, allows arbitrary >>>> customization of the search condition. >>> I understand the POV of both Evan and you here. However, I think that >>> there might be a good solution for this particular case - to allow >>> dropping functions by name only if it has the only signature, but if >>> there are 2 or more signatures then print an error specifying all the >>> forms of the function, eg.: >>> >>> ERROR: Can not drop function 'foo' because it has more then one >>> signature: foo(integer), foo(text). >> But that doesn't solve Evan's request. He would want both functions >> gone, not an error. > I was writing about some kind of a compromise. My point was precisely that a compromise would satisfy nobody. There would be a few cases for which it was Exactly The Right Thing, and many more for which you'd still need to learn how to do the EXECUTE trick. I wonder whether we shouldn't address this by adding a few examples of that type of trick to the docs. Not sure where, though ... regards, tom lane
В списке pgsql-general по дате отправления: