Re: patch (for 9.1) string functions - Mailing list pgsql-hackers

On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure <mmoncure@gmail.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".

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