Re: format() with embedded to_char() formatter

2010/11/22 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Nov 22, 2010 at 12:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane <tgl@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
>