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(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9