| From: | Jeff Davis <pgsql(at)j-davis(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: string_to_array has to be stable? | 
| Date: | 2010-07-29 00:51:09 | 
| Message-ID: | 1280364669.31397.8.camel@jdavis-ux.asterdata.local | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Wed, 2010-07-28 at 20:25 -0400, Tom Lane wrote:
> string_to_array() seems fine to me: it's a predictable transformation
> from text to text.  However, I think that there really is an issue with
> array_to_string(), because that takes an anyarray and invokes the array
> element's type output function. 
Yes, I misread the problem because he used "current_date" rather than a
date literal.
> I can't remember offhand whether there are any volatile type output
> functions, but if there were we'd really need to mark array_to_string()
> as volatile.  That would be unpleasant for performance though.   I'd
> rather compromise on stable.  Thoughts?
"Stable" seems reasonable to me.
A volatile type output function sounds like an edge case. Perhaps there
are even grounds to force a type output function to be stable, similar
to how we force the function for a functional index to be immutable.
Regards,
	Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Pflug | 2010-07-29 01:23:51 | Re: Patch to show individual statement latencies in pgbench output | 
| Previous Message | Tom Lane | 2010-07-29 00:25:35 | Re: string_to_array has to be stable? |