Re: string function - "format" function proposal

On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro
>> <itagaki.takahiro@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