2010/7/29 Tom Lane <t...@sss.pgh.pa.us>: > 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.
+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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers