Re: string_to_array has to be stable?

2010/7/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
>> On Wed, 2010-07-28 at 20:25 -0400, Tom Lane wrote:
>>> 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.
>
> I did a bit of research in the system catalogs, and found that the only
> built-in type output function that is marked volatile is record_out().
> I think this is probably from an excess of caution --- record_out has
> the same issue that it's really as volatile as the underlying per-column
> output functions.  I notice in particular that anyarray_out is marked
> stable, and of course it's got the same issue too.
>
> I propose changing both array_to_string() and record_out() to be marked
> stable, and that that be the default assumption for similar future cases
> as well.  This isn't something we can back-patch, but sneaking it into
> 9.0 at this point (without a catversion bump) seems reasonable to me.

+1

>
> I'm not in favor of trying to force output functions to be declared
> non-volatile as Jeff suggests above.  I think doing that would probably
> break user type definitions far and wide --- for a comparative sample,
> all of the user-defined types added in the standard regression tests
> would break, because we never bothered to mark their output functions
> as to volatility.  If we did do it, it would retroactively justify
> treating record_out and anyarray_out as stable, but I doubt it's worth
> causing a flag day for user-defined types.
>
> BTW, the situation on the input side is a bit different: record_in is
> volatile because domain_in is, and I think we'd better leave that alone
> since it's not too hard to believe that a domain might have volatile
> CHECK expressions.  If we had arrays of domains, anyarray_in would have
> to be volatile too, but we don't and it isn't.
>
>                        regards, tom lane
>