| From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: string function - "format" function proposal |
| Date: | 2010-10-18 11:37:24 |
| Message-ID: | AANLkTikzUJ9psVT2Aheee1VNS8bVXPaDhupKDkK4o3zb@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> No doubt. The problem is that we're going to end up with those bells
> and whistles in two places: in to_char or other type-specific
> formatting functions, and again in format.
If we decide to use C-like sprintf(), I think the only thing we can do
is to implement C-syntax as much as possible. Users will expect the
function behaves as sprintf, because it has the similar syntax.
It's not an item for now, but someone would request it at a future date.
BTW, the interoperability is why I proposed {} syntax. For example,
{1:YYYY-MM-DD} for date is expanded to to_char($1, 'YYYY-MM-DD').
(Maybe it's not so easy; It requires function lookups depending on types.)
--
Itagaki Takahiro
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-10-18 11:37:43 | Re: Extensions, this time with a patch |
| Previous Message | Itagaki Takahiro | 2010-10-18 10:56:03 | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |