On Mon, Nov 22, 2010 at 12:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers