Re: patch (for 9.1) string functions

2010/7/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> I'm just very skeptical that we should give our functions argument
>>> types that are essentially fantasy.  CONCAT() doesn't concatenate
>>> integers or intervals or boxes: it concatenates strings, and only
>>> strings.  Surely the right fix, if our casting rules are too
>>> restrictive, is to fix the casting rules; not to start adding a bunch
>>> of kludgery in every function we define.
>>>
>>> The problem with your canonical example (and the other examples of
>>> this type I've seen) is that they are underspecified.  Given two
>>> identically-named operators, one of which accepts types T1 and T2, and
>>> the other of which accepts types T3 and T4, what is one to do with T1
>>> OP T4?  You can cast T1 to T3 and call the first operator or you can
>>> cast T4 to T2 and call the second one, and it's really not clear which
>>> is right, so you had better thrown an error.  The same applies to
>>> functions: given foo(text) and foo(date) and the call
>>> foo('2010-04-15'), you had better complain, or you may end up with a
>>> very sad user.  But sometimes our current casting rules require casts
>>> in situations where they don't seem necessary, such as
>>> LPAD(integer_column, '0', 5).  That's not ambiguous because there's
>>> only one definition of LPAD, and the chances that the user will be
>>> unpleasantly surprised if you call it seem quite low.
>>>
>>> In other words, this problem is not unique to CONCAT().
>>
>> shoot, can't resist :-).
>>
>> Are the casting rules broken? If you want to do lpad w/o casts for
>> integers, you can define it explicitly -- feature, not bug.  You can
>> basically do this for any function with fixed arguments -- either in
>> userland or core.  lpad(int) actually introduces a problem case with
>> the minus sign possibly requiring application specific intervention,
>> so things are probably correct exactly as they are.
>
> Huh?  If you're arguing that LPAD should require a cast on an integer
> argument because the defined behavior of the function might not be
> what someone wants, then apparently explicit casts should be required
> in all cases.  If you're arguing that I can eliminate the need for an
> explicit cast by overloading LPAD(), I agree with you, but that's not
> a feature.
>
>> ISTM you are unhappy with the "any" variadic mechanism in general, not
>> the casting rules.
>
> No, I'm unhappy with the use of "any" to make an end-run around the
> casting rules.  If you're writing a function that operates on an
> argument of any type, like pg_sizeof() - or if you're writing a
> function that does something like append two arrays of unspecified but
> identical type or, perhaps, search an array of unspecified type for an
> element of that same type - or if you're writing a function where the
> types of the arguments can't be known in advance, like printf(), well,
> then any is what you need.  But the only argument anyone has put
> forward for making CONCAT() accept ANY instead of TEXT is that it
> might require casting otherwise.  My response to that is "well then
> you have to cast it, or fix the casting rules".

I understand, but with only text accepting, then CONCAT will has much
less benefit - you can't do a numeric list, for example

see concat(c1::text, ',', c2::text, ',' ...)

with this is much simpler use a pipes '' || c1 || ',' || c2 ... and
this operator does necessary cast self.

This function is probably one use case of exception from our rules.

Regards

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