Re: format() with embedded to_char() formatter
От | Tom Lane |
---|---|
Тема | Re: format() with embedded to_char() formatter |
Дата | |
Msg-id | 29170.1290446246@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: format() with embedded to_char() formatter (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: format() with embedded to_char() formatter
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> And lastly, AFAICS there >> is no way to do what you suggest without some really ugly kluges >> in the parser --- I think the function parsing code would have to >> have special cases to make format() work like this. > Huh? How exactly are you going to get from format('string here', timestamp_expr) to format('string here', to_char(timestamp_expr)) especially seeing that "to_char" is not one function but an overloaded family of functions (doubtless soon to become even more overloaded, if this proposal is adopted)? Or is the intention to replicate the parser's overloaded-function-resolution behavior at runtime? That seems awkward, duplicative, slow, and probably prone to security issues (think search_path). Or perhaps Itagaki-san intended to hard-wire a fixed set of to_char functions that format() knows about. That seems to lose whatever minor charms the proposal possessed, because it wouldn't be extensible without changing format()'s C code. regards, tom lane
В списке pgsql-hackers по дате отправления: