Re: ALTER TABLE schema SCHEMA TO new_schema?

I wonder if the sequences created by SERIAL should not be going into a 
pg_sequence schema and protected like the toast tables are.

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:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9