pgsql: Bumping catversion due to changes to pg_trigger and pg_rewrite.

Jan Wieck wrote:

BTW, the comment in this file says that we hope we never have more than
10 catversion changes per day, but to even make this possible we should
start counting at zero, shouldn't we?

The comment says "hopefully we'll never commit ten independent sets of
catalog changes on the same day" (not > 10), so the comment isn't wrong.
But I guess there wouldn't be any harm at starting at zero...

-Neil

On 3/20/2007 12:00 AM, Neil Conway wrote:

Jan Wieck wrote:

BTW, the comment in this file says that we hope we never have more than
10 catversion changes per day, but to even make this possible we should
start counting at zero, shouldn't we?

The comment says "hopefully we'll never commit ten independent sets of
catalog changes on the same day" (not > 10), so the comment isn't wrong.
But I guess there wouldn't be any harm at starting at zero...

Since the entire catversion number is used as an integer, counting 0...9
vs. 1...0 makes quite a difference. And that difference manifests itself

9, not >10.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Neil Conway <neilc@samurai.com> writes:

Jan Wieck wrote:

BTW, the comment in this file says that we hope we never have more than
10 catversion changes per day, but to even make this possible we should
start counting at zero, shouldn't we?

The comment says "hopefully we'll never commit ten independent sets of
catalog changes on the same day" (not > 10), so the comment isn't wrong.
But I guess there wouldn't be any harm at starting at zero...

Well, if we were seriously concerned about that we'd use 2 digits for NN
(and accept the risk that the scheme breaks down in 2147, if people are
still using Postgres and 32-bit ints then). But I don't think I've ever
seen N get as high as 3, so I'm not worried. Given that we have some
headroom there, I'd sooner stick with 1-based counting --- the YYYY,
MM, and DD parts of the value are 1-based so it seems odd to decree
that N is 0-based.

regards, tom lane

On 3/20/2007 12:08 AM, Jan Wieck wrote:

On 3/20/2007 12:00 AM, Neil Conway wrote:

Jan Wieck wrote:

BTW, the comment in this file says that we hope we never have more than
10 catversion changes per day, but to even make this possible we should
start counting at zero, shouldn't we?

The comment says "hopefully we'll never commit ten independent sets of
catalog changes on the same day" (not > 10), so the comment isn't wrong.
But I guess there wouldn't be any harm at starting at zero...

Since the entire catversion number is used as an integer, counting 0...9
vs. 1...0 makes quite a difference. And that difference manifests itself

9, not >10.

Sheesh ... yes, rereading your remark I get it. The comment is correct,
because the problem case is "10", no more and no less.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #