Re: Tom Lane 2014-11-05 <29132.1415144...@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 salt when presented with a
    not-yet-encrypted password.  This is bad because of the general assumption
    that I/O functions aren't volatile: the consequence is that records or
    arrays containing chkpass elements may have input behavior a bit different
    from a bare chkpass column.  But there seems no way to fix this without
    breaking existing usage patterns for chkpass, and the consequences of the
    inconsistency don't seem bad enough to justify that.  So for the moment,
    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
-- 
c...@df7cb.de | http://www.df7cb.de/


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to