On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers