Re: patch (for 9.1) string functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>
Subject: Re: patch (for 9.1) string functions
Date: 2010-07-27 00:48:46
Message-ID: AANLkTikouqVvXmE=eKUoJg8-ddXJvf-URwhi2P_1MccV@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure <mmoncure(at)gmail(dot)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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Tolley 2010-07-27 03:36:32 Re: Synchronous replication
Previous Message Robert Haas 2010-07-26 20:27:38 Re: dynamically allocating chunks from shared memory