Re: Tom Lane 2014-11-05 <29132.1415144894@sss.pgh.pa.us>
> I wrote:
> > An alternative that just occurred to me is to put the no-volatile-
> > I/O-functions check into CREATE TYPE, but make it just WARNING not
> > ERROR. That would be nearly as good as an ERROR in terms of nudging
> > people who'd accidentally omitted a volatility marking from their
> > custom types. But we could leave chkpass as-is and wait to see if
> > anyone complains "hey, why am I getting this warning?". If we don't
> > hear anyone complaining, maybe that means we can get away with changing
> > the type's behavior in 9.6 or later.
>
> Attached is a complete patch along these lines. As I suggested earlier,
> this just makes the relevant changes in ltree--1.0.sql and
> pg_trgm--1.1.sql without bumping their extension version numbers,
> since it doesn't seem important enough to justify a version bump.
>
> I propose that we could back-patch the immutability-additions in ltree and
> pg_trgm, since they won't hurt anything and might make life a little
> easier for future adopters of those modules. The WARNING additions should
> only go into HEAD though.
In HEAD, there's this WARNING now:
WARNING: type input function chkpass_in should not be volatile
From 66c029c842629958b3ae0d389f24ea3407225723:
A fly in the ointment is that chkpass_in actually is volatile, because of its use of random() to generate a fresh
saltwhen presented with a not-yet-encrypted password. This is bad because of the general assumption that I/O
functionsaren't volatile: the consequence is that records or arrays containing chkpass elements may have input
behaviora bit different from a bare chkpass column. But there seems no way to fix this without breaking existing
usagepatterns for chkpass, and the consequences of the inconsistency don't seem bad enough to justify that. So for
themoment, just document it in a comment.
IMHO built-in functions (even if only in contrib) shouldn't be raising
warnings - the user can't do anything about the warnings anyway, so
they shouldn't get notified in the first place.
(Catched by Debian's postgresql-common testsuite)
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
