Re: patch (for 9.1) string functions
От | Itagaki Takahiro |
---|---|
Тема | Re: patch (for 9.1) string functions |
Дата | |
Msg-id | AANLkTimyWtTMAmfpEU0UGeQuciZK4D2oQ8YtRT7NWwYc@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch (for 9.1) string functions (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: patch (for 9.1) string functions
Re: patch (for 9.1) string functions |
Список | pgsql-hackers |
I merged and enhanced some part of your patch: - contrib/stringfunc are merged in the core patch - Old format() is replaced with sprintf(), but the function name is still format(). - Support %q as alias for %iq. 2010/7/25 Pavel Stehule <pavel.stehule@gmail.com>: > fixed - it depends on INT64_FORMAT now. I modified the code a bit not to expect 'll' or 'l'. > %lq ... literal quoted > %iq ... ident quoted I also modified 'q' without specifier, i.e, %q is handled as same as %lq. >> But I found there is a design issue in format() : > I prefer a current behave - RAISE statement uses same and it is not > reported as bug for ten years I think RAISE is badly designed. Using % as a placeholder has a limitation to format strings. For example, format() cannot work as concat(): SELECT format('%%', 123, 456) => ERROR So, my proposal is renaming stringfunc//sprintf() to format(), and moving it into the core. I think sprintf() is superior to format() in every aspect; '%s%s' works as concat(), and '%s%%' can append % without blanks. Then, concat_ws() will be moved into core because contrib/stringfunc only has the function now. In addition, I'd like to include the function for the compatibility to MySQL. Also, concat() and concat_ws() can share the implementation. Comments? -- Itagaki Takahiro
Вложения
В списке pgsql-hackers по дате отправления: