Re: patch (for 9.1) string functions

2010/7/26 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
> 2010/7/26 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>