Re: proposal: fix corner use case of variadic fuctions usage

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: proposal: fix corner use case of variadic fuctions usage
Дата
Msg-id 50FC470B.9060402@dunslane.net
обсуждение исходный текст
Ответ на Re: proposal: fix corner use case of variadic fuctions usage  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: proposal: fix corner use case of variadic fuctions usage  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 01/20/2013 01:37 PM, Robert Haas wrote:
> On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> We introduced VARIADIC "any" function. Motivation for this kind of
>> function was bypassing postgresql's coerce rules - and own rules
>> implementation for requested functionality. Some builtins function
>> does it internally - but it is not possible for custom functions or it
>> is not possible without some change in parser. Same motivation is
>> reason why "format" function is VARIADIC "any" function.
> I'd just like to draw the attention of all assembled to the fact that
> this is another example of the cottage industry we've created in
> avoiding our own burdensome typecasting rules.  I not long ago
> proposed a patch that went nowhere which would have obviated the need
> for this sort of nonsense in a much more principled way, which of
> course went nowhere, despite the design being one which Tom himself
> proposed.  Is there any amount of this which will sway popular opinion
> to the point of view that the problem is not with the individual
> cases, but the rules themselves?


Uh, reference please? This doesn't jog my memory despite it being 
something that's obviously interesting in light of my recent work. (That 
could be a a case of dying synapses too.)

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: missing rename support
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: CF3+4 (was Re: Parallel query execution)