Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
> Hmm. I have a feeling that's going to be a rathole. Among other
> problems, what about types other than strings and numbers?
I think the general solution is to split those off as subproblems.
If you've got a type that has special formatting requirements,
you can do
sprintf('foo is %s', format_my_type(value, other-arguments))
where format_my_type returns text. (So, in particular, you could use
to_char for this if it solved the particular need.)
Having said that, it might make sense to provide special case handling
of dates and timestamps, since that's definitely the most common case
where you might not be satisfied with the default conversion to text.
> The specification for sprintf is
> ridiculously complicated with just the things C has as built-in types,
> never mind SQL.
Sure, but an awful lot of those bells and whistles turn out to be handy.
Personally I think the field width control options are the main thing
that sprintf has got over to_char, so I think we're going to want those
sooner rather than later.
> Then again, if I'm not the one who has to spend time in the rathole...
Yeah, I'm not in a hurry to spend time on it either. I just foresee
that somebody will want to, and so I don't want a dead-end definition.
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
