Re: variadic function support
От | Pavel Stehule |
---|---|
Тема | Re: variadic function support |
Дата | |
Msg-id | 162867790807140617s105a0a5ew61100897db52d23b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: variadic function support (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
2008/7/13 Tom Lane <tgl@sss.pgh.pa.us>: > "Pavel Stehule" <pavel.stehule@gmail.com> writes: >> 2008/7/13 Jeff Davis <pgsql@j-davis.com>: >>> Also, it doesn't seem to allow calls to a variadic function with zero >>> arguments, e.g. "mleast()". I think this should be allowed. > >> It's not possible for all cases, because empty array have be typed >> array still. But for non polymorphic variadic functions it's probably >> possible - I would to solve this question later - and for now use >> overloading etc > > I don't really like the idea of a feature that would work except in the > polymorphic case --- that just seems too non-orthogonal. Also I tend > to think that a pretty large fraction of variadic functions will be > polymorphic, making the feature's usefulness even more dubious. > > I concur with the idea that variadic functions should only match to > calls that offer at least one value for the variadic array. If you can > actually define the behavior sensibly for the zero-element case, a > separate function of the same name can cover that case. > > As far as the "variadic int" versus "variadic int[]" business, I'm > starting to agree with Pavel that "variadic int[]" offers less potential > for confusion. In particular, it seems to make it more obvious for the > function author that the argument he receives is an array. Also, the > other one would mean that what we put into pg_proc.proargtypes doesn't > agree directly with what the user thinks the argument types are. While > I think we could force that to work, it's not exactly satisfying the > principle of least surprise. > > > One issue that just occurred to me: what if a variadic function wants to > turn around and call another variadic function, passing the same array > argument on to the second one? This is closely akin to the problem > faced by C "..." functions, and the solutions are pretty ugly (sprintf > vs vsprintf for instance). Can we do any better? At least in the > polymorphic case, I'm not sure we can :-(. > fixed version Thanks for comments Pavel
Вложения
В списке pgsql-patches по дате отправления: