On Tue, Nov 27, 2012 at 4:09 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 11/27/12 12:07 PM, Merlin Moncure wrote:
>> Speaking of polymorphism, why not just implement lpad()'s first
>> argument as 'anyelement'?
>
> One of the arguments made here was that lpad(not-text) *should* fail.
Well, sure. My point is: why do we need to break the casting
machinery when we can simply tweak a few of the standard functions on
portability grounds?
Robert's case on lpad() has merit in the sense it has unambiguous
meaning regardless of input type; polymorphic input types were
designed to solve *exactly* that problem. SQL portability is a
secondary but also important argument.
That said, md5() surely needs some type of cast or interpretation of
non-text types. ditto to_timestamp(), etc. So messing around with
the casting rules is surely the wrong answer. I think if you relaxed
the function sigs of a few functions on this page
(http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
most reported problems would go away.
One thing that worries me is introducing ambiguous cases where
previously there weren't any though.
merlin
