On Fri, Sep 11, 2009 at 11:19 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >>> I think the main benefit of a sprintf type function for PostgreSQL is >>> in the formatting (setting length, scale, alignment), not in making >>> concatenation more pretty. >> >> Exactly, which is why I'm so distressed that this proposal not only >> hasn't got that, but is designed so that it's impossible to add it >> later. > > I like the idea of making concatenation more pretty, quite frankly. > No one has really responded to Pavel's contention that this is what > to_char() is for. Twice the code paths = twice the bugs, twice the > places that have to be updated when some new feature is added, etc.
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. The idea is we are not adding new formatting routines but using a very high quality existing one...why reinvent the wheel? so if you did: select printf('%s %3.1f', foo::box, bar::circle); the box to char* cast would work (using the text cast) but the second cast would fail unless the user added a cast to float. The code in question is easy to imagine...parse the format string, and loop the varargs using the appropriate looked up cast one by one... merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers