Skip site navigation (1) Skip section navigation (2)

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-29 20:53:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Jul 26, 2010 at 8:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

I believe that another unpleasant side effect of this is that CONCAT()
will have to be declared stable rather than immutable.

Robert Haas
The Enterprise Postgres Company

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-07-29 21:03:43
Subject: Re: reducing NUMERIC size for 9.1
Previous:From: Robert HaasDate: 2010-07-29 20:51:22
Subject: Re: merge command - GSoC progress

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group