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.


Pavel Stehule

> --
> Itagaki Takahiro

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to