2010/7/26 Itagaki Takahiro <itagaki.takah...@gmail.com>: > 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.steh...@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. >
Sorry, I am strong against. Using a format just for string string concation is bad idea - there are a concat function, there are || operator. Look on complexity of format/RAISE and sprintf. More - it can be strange, when we have a "format" function and it is almost "sprintf". I still prefer simplicity of format - you have a true - it has a issue, but there are simply workaround format('%', 123||345) format is very simple - but usually you don't need to specify a with, a precision. sprintf has some issue based on common sprintf implementation and expecting too. For example a precision is used very dynamically - it has a different sense for integers and for floats, so I wouldn't have a sprintf in core. > 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? I disagree - please, return to prev variant Regards Pavel Stehule > > -- > 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