2009/9/11 Tom Lane <tgl@sss.pgh.pa.us>:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> If you are going to use printf format codes, which is good and useful
>> being something of a standard, I'd call routine printf (not format)
>> and actually wrap vsnprintf. The format codes in printf have a very
>> specific meaning: converting native C types to arrays of characters.
>> I think that a postgresql implementation should do exactly that:
>> attempt to convert the passed in datum to the c type in question if
>> possible (erroring if no cast exists) and then pass it down.
>
> I think this is a bit too restrictive. Aside from the issue of loss of
> precision for NUMERIC, do we really want users to have to deal with the
> fact that "long" doesn't mean the same thing on every platform? I don't
> want the same SQL to work on some platforms and fail on others because
> a particular datatype has a cast to int4 and not to int8, for instance.
>
> We should certainly leverage the C library as much as we can for this,
> but exposing users to every single idiosyncrasy of C is not quite the
> right thing IMHO.
>
I am thinking so PostgreSQL sprintf function that isn't real sprintf
function is really perfect idea. I see messages, sprintf doesn't
support format correctly ... And I will have three sprintf functions,
perl, c and postgres, ... still are you thinking, so this is good
idea?
regards
Pavel Stehule
> regards, tom lane
>
