From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Hackers <pgsql-hackers(at)postgresql(dot)org>, Rod Taylor <rbt(at)rbt(dot)ca> |
Subject: | Re: bug in 7.4 SET WITHOUT OIDs |
Date: | 2004-03-24 01:41:15 |
Message-ID: | 4060E73B.2010705@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I am currently testing a fix that allows you to say
> ALTER TABLE DROP COLUMN oid;
> which will behave the same way a regular user-column DROP would.
>
> I intend to interpret SET WITHOUT OIDS as DROP COLUMN oid RESTRICT.
Will it handle this case:
usa=# create table testy (a int4) without oids;
CREATE TABLE
usa=# alter table testy add oid int4;
ALTER TABLE
usa=# \d testy
Table "public.testy"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
oid | integer |
How about the syntax:
ALTER TABLE t DROP OIDS;
This I can make:
ALTER TABLE t DROP CLUSTER;
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-03-24 02:16:08 | Re: float8 regression test failure in head |
Previous Message | Christopher Kings-Lynne | 2004-03-24 01:38:09 | Re: Chapter on PostreSQL in a book |