Re: string function - "format" function proposal

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: string function - "format" function proposal
Дата
Msg-id AANLkTik6uM84u-WKT4CWKSnVd9ZUdpzBaXO2En9u9J_V@mail.gmail.com
обсуждение исходный текст
Ответ на Re: string function - "format" function proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: string function - "format" function proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2010/9/6 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2010/9/6 Itagaki Takahiro <itagaki.takahiro@gmail.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
>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Itagaki Takahiro
Дата:
Сообщение: Re: string function - "format" function proposal
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: string function - "format" function proposal