From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: string function - "format" function proposal |
Date: | 2010-09-06 14:28:29 |
Message-ID: | 26947.1283783309@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> Why I think so this is useful - sometimes people asked some GUC for
> formatting date, boolean and other. If these functions try to use a
> cast to text first, then there is some space for customization via
> custom cast functions.
This is basically nonsense. If you don't control a type's output
function, you don't control its cast to text either. Nor do I think
it's a good idea to encourage people to make their casts to text operate
differently from their output functions. We have that one wart in
boolean casting because the SQL standard specifies the result of cast to
text and it's different from our historical practice in the bool output
function --- but it is a wart, not something we should encourage people
to emulate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2010-09-06 14:51:34 | Re: string function - "format" function proposal |
Previous Message | Tom Lane | 2010-09-06 14:24:08 | Re: string function - "format" function proposal |