Re: format() with embedded to_char() formatter

On Tue, Nov 23, 2010 at 03:08, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>> 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.

I've thought lookup_agg_function() is available for the purpose, but
type coercion is required in some cases, for example, to_char(date).
The parser performs the task in normal cases, but format() does it
in execution time. I have no solution for the issue.

>>> 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.
>>
> The implementation should not be complex or ugly,  but it can returns
> back dependency problem.

Hard-wired approach might be a bit safer than the above because we
can restrict acceptable set of types. However, we might need to add
additional to_char() functions for often-used types to avoid errors,
especially for date and int2 types.

Just for reference, I attached my past works. It would be a bad
design as discussed above, but it would be a help to see in which
case the approach doesn't work.

--
Itagaki Takahiro