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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: dblink versus long connection strings
Следующее
От: Tom Lane
Дата:
Сообщение: Re: dblink versus long connection strings