Re: ALTER TABLE schema SCHEMA TO new_schema?

From: Joe Conway <mail(at)joeconway(dot)com>
To: Fernando Nasser <fnasser(at)redhat(dot)com>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE schema SCHEMA TO new_schema?
Date: 2002-12-02 17:28:22
Message-ID: 3DEB9836.2090806@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-12-02 17:50:03 protecting prosrc (was Re: USAGE on schema allowed by default?)
Previous Message Nicolai Tufar 2002-12-02 16:58:38 Patch to make Turks happy.