From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: format() with embedded to_char() formatter |
Date: | 2010-11-22 17:17:26 |
Message-ID: | 29170.1290446246@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-22 17:21:36 | Re: dblink versus long connection strings |
Previous Message | Andrew Dunstan | 2010-11-22 17:12:41 | Re: dblink versus long connection strings |