On Mon, Nov 22, 2010 at 12:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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).
Ick.
> 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.
Extensibility would be (really) nice to have, but the feature may have
some merit even without that. I certainly spend a lot more time
formatting built-in types than custom ones.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company