I understand that RULES are like macros.
Strangest thing here is that INSERT to test1 will touch only one
sequence: test1_id_seq.
And it increments test1_id_seq twice during insert with RULE.
Then all sequence procedures like lastval() and currval() will return
number (as stated in report),
which is biger than actualy one inserted into the database.
When after insert:
BEGIN; INSERT INTO test1(some_text) VALUES ('test1'); SELECT lastval()
as id; END;
you make a select on test1 and test_log1 tables you see such a view:
testdb=# select * from test1;
id | some_text
----+-----------
2 | test1
(1 row)
testdb=# select * from test_log1;
qid | when_happened
-----+----------------------------
3 | 2005-11-16 10:27:33.100913
(1 row)
Sarunas
Tomas Zerolo wrote:
On Tue, Nov 15, 2005 at 10:51:10PM -0700, Michael Fuhr wrote:
On Wed, Nov 16, 2005 at 06:29:40AM +0100, Tomas Zerolo wrote:
AFAIK, serials are not guaranteed to produce sequential values; tehy
will produce unique values. That means that they can (and sometimes
will) jump.
In this particular case, however, the behavior is due to the rule
on test1:
CREATE RULE test1_on_insert AS ON INSERT TO test1
DO INSERT INTO test_log1 (qid) VALUES (new.id);
[...]
Oops, I didn't see that. Your eyes are sharper than mine ;-)
thanks
-- tomas
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
