On Tue, Nov 23, 2010 at 03:08, Pavel Stehule <pavel.steh...@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
format_with_to_char-20101125.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers