Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Yep, Tom fixed it good.
>
> Was this another of those darn regurgitated-from-February messages?
> I'm about ready to go out and acquire missile targeting coordinates
> for pcbuddy.com ...
No, it was me cleaning out my old e
Was this another of those darn regurgitated-from-February messages?
I'm about ready to go out and acquire missile targeting coordinates
for pcbuddy.com ...
Hmmm, maybe - I don't have the email any more though, as I deleted it :(
I get regurgitated emails all the time - it can be quite confusing...
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Yep, Tom fixed it good.
Was this another of those darn regurgitated-from-February messages?
I'm about ready to go out and acquire missile targeting coordinates
for pcbuddy.com ...
regards, tom lane
Yep, Tom fixed it good.
Bruce Momjian wrote:
I can confirm that current CVS handles this OK.
---
Christopher Kings-Lynne wrote:
I had a suspicion and it was confirmed:
test=# create table oidtest (a int4, unique(oid));
NOTICE:
I can confirm that current CVS handles this OK.
---
Christopher Kings-Lynne wrote:
> I had a suspicion and it was confirmed:
>
> test=# create table oidtest (a int4, unique(oid));
> NOTICE: CREATE TABLE / UNIQUE will creat
If you have one (implying that you don't have a system OID column) then
"DROP COLUMN oid" will drop it, but "SET WITHOUT OIDS" will not. Okay
with you?
Sounds fair.
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What I meant is - does it handle dropping a non-system 'oid' column?
> ie. A user column that just happens to be named 'oid'.
If you have one (implying that you don't have a system OID column) then
"DROP COLUMN oid" will drop it, but "SET WITH
Will it handle this case:
usa=# create table testy (a int4) without oids;
usa=# alter table testy add oid int4;
No. This is DROP not ADD.
What I meant is - does it handle dropping a non-system 'oid' column?
ie. A user column that just happens to be named 'oid'.
Chris
-
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> 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.
> Will it handle this case:
> usa=# create table testy (a int4) without oids;
> usa=# alter
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;
CR
Robert Treat <[EMAIL PROTECTED]> writes:
> Point being that in the original case, I think the index on the oid column
> should be dropped automagically, to follow similar behavior with normal
> columns.
I am currently testing a fix that allows you to say
ALTER TABLE DROP COLUMN oid;
whi
On Tuesday 23 March 2004 02:34, Christopher Kings-Lynne wrote:
> >>Maybe it needs CASCADE/RESTRICT added?
> >
> > Seems like overkill, considering that this is a very marginal feature.
> > I'm happy to decree that it works in whichever way is the easiest to
> > implement.
>
> In that case, it seems
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seems it should behave just like dropping a column of a table that
> already has an index on it:
Yeah. In fact, I am now wondering why we invented SET WITHOUT OIDS at
all, rather than making DROP COLUMN allow the target to be OID.
Christopher Kings-Lynne wrote:
> >>Maybe it needs CASCADE/RESTRICT added?
> >
> > Seems like overkill, considering that this is a very marginal feature.
> > I'm happy to decree that it works in whichever way is the easiest to
> > implement.
>
> In that case, it seems to me that it has to be defau
Maybe it needs CASCADE/RESTRICT added?
Seems like overkill, considering that this is a very marginal feature.
I'm happy to decree that it works in whichever way is the easiest to
implement.
In that case, it seems to me that it has to be default RESTRICT. If
anything depend on it, it must fail. O
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> The problem appears to be that ALTER TABLE SET WITHOUT OIDS doesn't make
>> the index on the OID column go away.
> Maybe it needs CASCADE/RESTRICT added?
Seems like overkill, considering that this is a very marginal feature.
I'm happy to decr
The problem appears to be that ALTER TABLE SET WITHOUT OIDS doesn't make
the index on the OID column go away.
I don't have a strong opinion on whether to fix this by forcing a drop
of the index or by rejecting the ALTER command. Seems like we have to
do one or the other though.
This is actually ju
17 matches
Mail list logo
