Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Not entirely sure what to do about this. It seems like for the purposes
>> of contrib/chkpass, it's a good thing that chkpass_in() won't reuse the
>> same salt. Weak as a 12-bit salt might be nowadays, it's still better
>> than no salt. Nonetheless, this behavior is breaking assumptions made
>> in places like array_in and record_in.
>>
>> For the moment I'm tempted to mark chkpass_in as stable (with a comment
>> explaining that it isn't really) just so we can put in the error check
>> in CREATE TYPE. But I wonder if anyone has a better idea.
> Can we have a separate function that accepts unencrypted passwords, and
> change chkpass_in to only accept encrypted ones? Similar to
> to_tsquery() et al.
Well, that would undoubtedly have been a better way to design the module
to start with, but we're not working in a green field. I doubt we can
get away with changing the type's behavior that much. That is, assuming
there are any users of it at all, which there might not be ;-)
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.
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
