Re: patch (for 9.1) string functions
От | Robert Haas |
---|---|
Тема | Re: patch (for 9.1) string functions |
Дата | |
Msg-id | AANLkTimwJ-MzG_dT+vYSyJ73H80dF1ER=9j-RzXMw0Pm@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch (for 9.1) string functions (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Mon, Jul 26, 2010 at 8:48 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure <mmoncure@gmail.com> wrote: >> concat() is not a variadic text function. it is variadic "any" that >> happens to do text coercion (not casting) inside the function. The >> the assumption that concat is casting internally is probably wrong. >> Suppose I had hacked the int->text cast to call a custom function -- I >> would very much expect concat() not to produce output from that >> function, just the vanilla output text (I could always force the cast >> if I wanted to). >> >> concat is just a function that does something highly similar to >> casting. suppose I had a function count_memory(variadic "any") that >> summed memory usage of input args -- forcing casts would make no sense >> in that context (I'm not suggesting that you think so -- just bringing >> up a case that illustrates how forcing cast into the function can >> change behavior in subtle ways). > > Right, but I already said I wasn't objecting to the use of variadic > ANY in cases like that - only in cases where, as here, you were > basically taking any old arguments and forcing them all to text. I believe that another unpleasant side effect of this is that CONCAT() will have to be declared stable rather than immutable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: