Skip site navigation (1) Skip section navigation (2)

Re: string function - "format" function proposal

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:04:07
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
2010/9/6 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2010/9/6 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
>>> Which should we use for such purposes? Consistent behavior is
>>> obviously preferred. Boolean type might be the only type that
>>> is converted to different representation in typoutput or cast-to-test,
>>> but we should consider to have boolean-specific hardwired code,
>>> or cast all types to text instead of output functions.
>> Personally I prefer casting to text -
> No, you need to use the I/O functions.  Not every type is guaranteed to
> have a cast to text.
>> iit allows some later
>> customizations. And it's more consistent with || operator.
> I don't buy either of those arguments.

can we use a both? like plpgsql? First check cast to text, and second
use a IO functions?

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.


Pavel Stehule

>                        regards, tom lane

In response to


pgsql-hackers by date

Next:From: Itagaki TakahiroDate: 2010-09-06 14:04:25
Subject: Re: string function - "format" function proposal
Previous:From: Tom LaneDate: 2010-09-06 14:01:46
Subject: Re: git: uh-oh

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group