Re: Not quite a security hole in internal_in

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> Normally we would consider a pg_proc change as requiring a catversion
>> bump. Since we are already past 8.4 beta we couldn't do that without
>> forcing an initdb for beta testers.

> I think a serious issue like this warrants a bump. It seems like you are
> saying that at any other time in the release cycle this would be
> an automatic bump, so let's keep a consistent policy and bump it.

This type of argument comes up all the time during beta period, and
we have made the decision both ways in the past. There isn't a
"consistent policy" about it, it's case-by-case.

The reason we bump catversion during development cycles is to keep
developers from wasting their time chasing imaginary bugs when their
backend executable is subtly incompatible with the contents of their
databases. (As happened more than a few times, before we invented
catversion :-(.) The bump is "automatic" only because it's cheaper to
just do it than to think hard about whether you've created such a risk.
This change doesn't create any compatibility issues of that sort, and
unlike in development, there is a real cost to a catversion bump ---
it will force an extra initdb on beta testers, who may have loaded
databases of considerable size.

For production releases, the argument to bump catversion is to be real
sure that all 8.4 (or whatever) installations have the same initial
catalog contents. That argument does apply here, but since this is just
a protective change and not known to be needed to prevent any live bug,
I don't think it's worth complicating beta testers' lives for.

regards, tom lane