2009/9/11 Tom Lane <t...@sss.pgh.pa.us>: > Merlin Moncure <mmonc...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers