Re: [HACKERS] format() with embedded to_char() formatter
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
[HACKERS] format() with embedded to_char() formatter
format() function is very useful to construct formatted text, but it doesn't support embedded formatter unlike sprintf() in C. Of course, we can use to_char() functions for each argument value, but embedded formatter would be more readable. I'd like to propose %{...}s syntax, where format('%{xxx}s', arg) is equivalent to format('%s', to_char(arg, 'xxx')). I think the approach is better than implement C-like formatter because we can reuse existing to_char() functions for the purpose. Here are examples for the usage: =# SELECT format('%{FM}s : %{-MM-DD}L', 123, current_timestamp); format - 0123 : '2010-11-22' =# SELECT format('CREATE TABLE partition_%{MMDD}s () INHERITS parent', current_date); format CREATE TABLE partition_20101122 () INHERITS parent Is it interesting? Comments welcome. -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] format() with embedded to_char() formatter
Hello There is little bit complication. There are no one to_char function - so you cannot to use DirectFunctionCall API. but I am not against to this proposal. regards Pavel 2010/11/22 Itagaki Takahiro itagaki.takah...@gmail.com: format() function is very useful to construct formatted text, but it doesn't support embedded formatter unlike sprintf() in C. Of course, we can use to_char() functions for each argument value, but embedded formatter would be more readable. I'd like to propose %{...}s syntax, where format('%{xxx}s', arg) is equivalent to format('%s', to_char(arg, 'xxx')). I think the approach is better than implement C-like formatter because we can reuse existing to_char() functions for the purpose. Here are examples for the usage: =# SELECT format('%{FM}s : %{-MM-DD}L', 123, current_timestamp); format - 0123 : '2010-11-22' =# SELECT format('CREATE TABLE partition_%{MMDD}s () INHERITS parent', current_date); format CREATE TABLE partition_20101122 () INHERITS parent Is it interesting? Comments welcome. -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] format() with embedded to_char() formatter
Itagaki Takahiro itagaki.takah...@gmail.com writes: I'd like to propose %{...}s syntax, where format('%{xxx}s', arg) is equivalent to format('%s', to_char(arg, 'xxx')). I think the approach is better than implement C-like formatter because we can reuse existing to_char() functions for the purpose. This seems pretty gross, not least because the existing to_char functions are so limited and broken. I don't really want to make format() incorporate all the brain damage in timestamp to_char, in particular. Also, it doesn't seem that you're really getting much notational leverage with this proposal. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] format() with embedded to_char() formatter
On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote: Itagaki Takahiro itagaki.takah...@gmail.com writes: I'd like to propose %{...}s syntax, where format('%{xxx}s', arg) is equivalent to format('%s', to_char(arg, 'xxx')). I think the approach is better than implement C-like formatter because we can reuse existing to_char() functions for the purpose. This seems pretty gross, not least because the existing to_char functions are so limited and broken. I don't really want to make format() incorporate all the brain damage in timestamp to_char, in particular. If the existing to_char() functions are limited and broken, maybe we ought to fix them. I am reminded of some wit's quote that XML is like violence - if it doesn't solve your problem, you aren't using enough of it. I'm not a believer in that philosophy, and don't think that adding a whole new set of functions with incompatible semantics is the right way to fix problems with the existing functions. We have enough of that already - especially around dates - and it sucks badly enough as it is. Non-orthogonality is bad. Also, it doesn't seem that you're really getting much notational leverage with this proposal. I am not sure I agree. It seems quite convenient to me to be able to encode all the formatting crap in the message string, rather than spreading it out all over the SQL statement. Maybe time for another poll on -general. 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? -- 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
Re: [HACKERS] format() with embedded to_char() formatter
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). 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] format() with embedded to_char() formatter
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
Re: [HACKERS] format() with embedded to_char() formatter
2010/11/22 Robert Haas robertmh...@gmail.com: 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)? a code for this is available now - if there is a some break, then it is a search_path. But this is a general problem. Probably isn't significant problem to limit search_path just for pg_catalog. 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. The implementation should not be complex or ugly, but it can returns back dependency problem. Regards Pavel Stehule -- 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers