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
|
Список | 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 по дате отправления: