Jeff Davis <pg...@j-davis.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers