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 email.
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 create
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:
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
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 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 default RESTRICT.
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.
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 to me that
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;
which
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 table
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:
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 WITHOUT
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
I had a suspicion and it was confirmed:
test=# create table oidtest (a int4, unique(oid));
NOTICE: CREATE TABLE / UNIQUE will create implicit index
oidtest_oid_key for table oidtest
CREATE TABLE
test=# select oid from oidtest;
oid
-
(0 rows)
test=# alter table oidtest set without oids;
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
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 decree
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.
I have seen that a bug related to duplicated keys is in 7.4rc2. As far
as I have seen a bug like that has already been discovered during the
7.3 era. Is this bug going to be fixed?
Here s the description:
DROP TABLE public.testtabelle;
begin;
CREATE TABLE public.testtabelle
(
c000
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
I have seen that a bug related to duplicated keys is in 7.4rc2. As far
as I have seen a bug like that has already been discovered during the
7.3 era. Is this bug going to be fixed?
We do not have, and never have had, deferred
PostgreSQL seems to maintance the unique index when updating each row.
If the insert sequence is 1, 2, 3, 4, 5, when doing
UPDATE testtabelle SET c001 = c001 - 1
It happens to process rows 1, 2, 3, 4, 5 in the same order as you insert.
Thus we see the UPDATE finished successfully. But, if
20 matches
Mail list logo
