Thanks Bruce.
I think by using the word 'constraint' I understand what the documentation
meant.
Both my queries (samples given below) arose from the fact that although
there was a 'relation', this is probably not what the documentation was
talking about.
Q1:
postgres=# CREATE TABLE serialTest3 (f1 bigint);
CREATE TABLE
postgres=# CREATE SEQUENCE seq4 OWNED BY serialTest3.f1;
CREATE SEQUENCE
postgres=# DROP SEQUENCE seq4;
DROP SEQUENCE
postgres=#
Q2:
postgres=# CREATE TABLE serialTest3 (f1 bigint);
CREATE TABLE
postgres=# CREATE SEQUENCE seq4 OWNED BY serialTest3.f1;
CREATE SEQUENCE
postgres=# ALTER TABLE serialTest3 DROP COLUMN f1 RESTRICT;
ALTER TABLE
postgres=#
I was working on some regression tests and then just wanted to be sure that
this (Q2 in particular) was perfectly legal, before adding checks for them.
Thanks again.
--
Robins
Tharakan
---------- Forwarded message ----------
I had to dig a little bit on this. The "dependent" object would be the
removal of the constraint depending on the sequence. Here is an
example:
test=> create table test (x serial);
CREATE TABLE
test=> \d test
Table "public.test"
Column | Type | Modifiers
--------+---------+--------------------------------------------------
x | integer | not null default nextval('test_x_seq'::regclass)
test=> \ds
List of relations
Schema | Name | Type | Owner
--------+------------+----------+----------
public | test_x_seq | sequence | postgres
(1 row)
--> test=> drop sequence test_x_seq;
ERROR: cannot drop sequence test_x_seq because other objects
depend on it
DETAIL: default for table test column x depends on sequence
test_x_seq
HINT: Use DROP ... CASCADE to drop the dependent objects too.
--> test=> drop sequence test_x_seq cascade;
NOTICE: drop cascades to default for table test column x
DROP SEQUENCE
test=> \d test
Table "public.test"
Column | Type | Modifiers
--------+---------+-----------
x | integer | not null
If this does not answer your questions, please post queries showing the
problem. Thanks.
