On Thu, 18 Oct 2007, Tom Lane wrote:
Looks like any alter sequence command will do this. The serial case uses
alter sequence owned by under the hood which exposes this. The problem is
that altering the sequence puts it into the SeqTable cache list when it
really shouldn't be.
It's not that
Julius Stroffek wrote:
There is only one option that comes to my mind - always return
Statment.SUCCESS_NO_INFO in executeBatch (or possibly only depending on
some java property). I can not see any simple solution for
Statement.executeUpdate since the number of rows affected may differ
dependi
Kris Jurka <[EMAIL PROTECTED]> writes:
>> jurka=# create table t (c serial);
>> NOTICE: CREATE TABLE will create implicit sequence "t_c_seq" for serial
>> column "t.c"
>> CREATE TABLE
>> jurka=# select currval('t_c_seq');
>> currval
>> -
>> 1
>> (1 row)
>>
>> I would expect it to say tha
On Thu, 18 Oct 2007, Kris Jurka wrote:
jurka=# create table t (c serial);
NOTICE: CREATE TABLE will create implicit sequence "t_c_seq" for serial
column "t.c"
CREATE TABLE
jurka=# select currval('t_c_seq');
currval
-
1
(1 row)
I would expect it to say that currval wasn't set
jurka=# create table t (c serial);
NOTICE: CREATE TABLE will create implicit sequence "t_c_seq" for serial
column "t.c"
CREATE TABLE
jurka=# select currval('t_c_seq');
currval
-
1
(1 row)
I would expect it to say that currval wasn't set like so:
jurka=# create sequence myseq;
Hi,
please see my comments inline.
Tom Lane wrote:
Julius Stroffek <[EMAIL PROTECTED]> writes:
Attached is the example script 'repro.sql' which creates two relations
tab1 and tab2. It also creates a rule on tab1 which simply does insert
into tab2. The insert statement into tab1 is executed
