On Fri, Sep 11, 2009 at 12:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
hmm. how about leaving the existing format codes alone and making some
safer additional ones that we advice the user to use? It could
probably be all fixed up in the vsnprintf layer.
merlin
