From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: format() with embedded to_char() formatter |
Date: | 2010-11-25 07:52:51 |
Message-ID: | AANLkTimUDG_bXpN_mC3b3ci1atikaGCzQ9M_cJwHuZOW@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
format_with_to_char-20101125.patch | application/octet-stream | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-11-25 07:59:48 | Re: Assertion failure on hot standby |
Previous Message | Shigeru HANADA | 2010-11-25 07:34:37 | SQL/MED - core functionality |