2010/7/26 Itagaki Takahiro <itagaki.takah...@gmail.com>: > 2010/7/26 Pavel Stehule <pavel.steh...@gmail.com>: >> 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. > > Why do we need to have similar functions in core and contrib? > It will just confuse users. If you want to RAISE-version of format(), > I don't want to have stringfunc in contrib. >
:( please, look back to discus about this module. There was desided, so "format" will be in core and "sprintf" in contrib. One reason for this decision was complexity of printf's implementation. > sprintf() is cool! So, I'd like to use sprintf() by default rather than > format() which has limited features. Almost all users don't know > well about contrib modules. Books about functions in inter-databases > don't consider about postgres' contrib modules. That's why I want to > move the useful features into core rather than contrib modules. > I have a different opinion and I am not alone. sprintf is good for c language, but it is problematic in scripting environments, where are not pointers, where we have more info about variables - where we can use a introspection - it is like dinosaurus in IT. My implementation is little bit simple, bacause it is use a buildin functionality - but still it has more then hundred rows. The full implementation has about thousand rows. More sprintf is little bit slower than format - it have to do little bit more work - and it can be confusing for people who doesn't known it well. for example - sprintf("%d", 10.2) ---> 10. next - sprintf respect common standard - but this standard doesn't calculate with PostgreSQL datatypes - there are not support for "date", "timestemp" for example. Function format is designed to work with builtin function to_char. This is simple and full functional combination - I have not a plan to replace it. 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