Re: string_to_array has to be stable?

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.

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