Sequence Cleanup

Below is a short list of TODOs on sequences I wish to tackle over the
next week.

CREATE SEQUENCE:
- Addition of NO MAXVALUE and NO MINVALUE options, which use the system
implementation settings -- for SQL2002 compliance, and makes ALTER
SEQUENCE slightly easier.

ALTER SEQUENCE:
- Supports RESTART WITH, + options from Create Statement (including NO
MAXVALUE, NO MINVALUE).

Modify init_params to deal with seq->options only. This allows
AlterSequence to use it as well.

Ok, this is where it gets confusing. Right now setval() is implemented
in such a manner that it cannot be rolled back (see SETVAL NOTE below),
but I'd like ALTER SEQUENCE to be transaction safe. Can I assume that
a standard simple_heap_update() is valid against the sequence, so long
as I set xmin = FrozenTransactionId and create 2 XLog records similarly
to DefineSequence?

Now, do I need to do anything to clear the cache of other backends, or
simply let them play themselves out. I'm leaning towards the latter, as
nextval() appears to read in the min / max value from the sequence
buffer.

A transaction safe alter sequence, implemented in the standard method,
will result in two tuples. Doing this many times could make sequences
quite slow. It looks like read_info() depends on a single value value
in the sequence table. Do I need to do something more complex like a
relfileswap, generating a fresh tuple for it -- all parts of
DefineSequence() except the DefineRelation() step?

Anyway, I'll fiddle with the above two approaches, but would appreciate
input where appropriate.

-- SETVAL NOTE --
a=# select nextval('test');
nextval
---------
2
(1 row)

a=# begin;
BEGIN
a=# select setval('test', 50);
setval
--------
50
(1 row)

a=# select nextval('test');
nextval
---------
51
(1 row)

a=# rollback;
ROLLBACK
a=# select nextval('test');
nextval
---------
52
(1 row)

--
Rod Taylor <rbt(at)rbt(dot)ca>

PGP Key: http://www.rbt.ca/rbtpub.asc