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: AANLkTik6uM84u-WKT4CWKSnVd9ZUdpzBaXO2En9u9J_V@mail.gmail.com (view raw or flat)
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.

Regards

Pavel Stehule

>
>                        regards, tom lane
>

In response to

Responses

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-2014 The PostgreSQL Global Development Group