On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro >> <itagaki.takah...@gmail.com> wrote: >>> I agree that full-spec sprintf is too complex, but precision and >>> zero-full for numeric types are commonly used. I think someone >>> will ask us "Why don't have numeric formats though we have %s?". > >> I think someone might also ask - why are you bothering to create this >> at all? The amount of work that has been put into this is, IMHO, far >> out of proportion to the value of the feature. As Pavel points out, >> we already have perfectly good mechanisms for converting our various >> data types to text. We do not need to invent new ones. > > I beg to differ. IMO to_char is a lot closer to the "sucks big-time" > end of the spectrum than the "perfectly good" end of the spectrum: > it's a bad implementation of a crummy design. I think a lot of people > would like to have something closer to sprintf-style formatting. > > I think we should go into this with the idea that it might only do 10% > of what sprintf can do initially, but there will be pressure to cover a > lot of the other 90% eventually. So it would be a good idea to ensure > that we don't make any choices that are gratuitously incompatible with > standard sprintf format codes. In particular, I agree with the idea of > using %I not %i for identifiers --- in fact I'd go so far as to suggest > that all specifiers we invent, rather than borrowing from sprintf, be > upper-case.
Hmm. I have a feeling that's going to be a rathole. Among other problems, what about types other than strings and numbers? The thing I most often need to format is a date, and the second most common one is timestamp with time zone. The specification for sprintf is ridiculously complicated with just the things C has as built-in types, never mind SQL. Then again, if I'm not the one who has to spend time in the rathole... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
