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