On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> I made a discussion page in wiki for the compatibility issue.
>> http://wiki.postgresql.org/wiki/String_Functions_and_Operators_Compatibility
> nice, thank you
I filled cells for SQL Server and DB2.
>> * concat() is not compatible between MySQL and Oracle/DB2. Which do we buy?
> I prefer a our implementation - it skip a NULL values and it has a
> variadic arguments.
OK. I'm going to put both concat() and concat_ws() into core.
>> * How do other databases behave in left() and right() with negative lengths?
> little bit by python substring operations.
I'll respect your proposal. The behaviors for negative lengths will
be our specific feature, but I don't see any problems there.
Since other databases raises errors, user should have negative-protections
in their existing codes.
> I don't agree. This function isn't designed to replace string
> concation. It is designed to build a SQL string (for dynamic SQL) or
> format messages. It isn't designed to replace to_char function. It is
> designed to work mainly inside PLpgSQL functions and then is
> consistent with RAISE statement.
OK. I'll revert my changes to your original format().
But please wait a moment to include sprintf() and contrib/stringfunc.
I think the function is useful, but don't want to have two versions
of formatting functions. So, the extended features will be merged
into format() with additional syntax something like {10s}. Then,
we could simplify the code because some of complex format syntax
are not so useful in SQL, especially length+string formatter (*s).
--
Itagaki Takahiro