One could still share sequences by explicitly creating them and using a DEFAULT clause with nextval().
We could even stop printing that annoying NOTICE ;-)
Regards,
Fernando
Joe Conway wrote:
Fernando Nasser wrote:Why not just leave the sequence and types in the original schema and make sure the table refers to them _there_? We just need to make sure we have schema qualified references to the sequences and types.
Well, the type entry for the relation *is* related to just one table, so I'd be inclined to move it also. But leaving the sequence alone might be the best thing to do. Although, I think sequences created via SERIAL are dropped with their referencing table now, aren't they?
test=# create table myserial(id serial);
NOTICE: CREATE TABLE will create implicit sequence 'myserial_id_seq' for SERIAL column 'myserial.id'
CREATE TABLE
test=# \ds myserial_id_seq
List of relations
Schema | Name | Type | Owner
--------+-----------------+----------+----------
public | myserial_id_seq | sequence | postgres
(1 row)
test=# drop table myserial;
DROP TABLE
test=# \ds myserial_id_seq
No matching relations found.
Maybe that's an argument that they ought to also move to the new schema when the dependency exists.
Indexes, triggers (and constraints), toast tables etc. are related to just one table so they can migrate together, I think.
I agree. Joe
-- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
