From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
Cc: | mdoggett(at)coas(dot)oregonstate(dot)edu, "[pgADMIN]" <pgadmin-support(at)postgresql(dot)org> |
Subject: | Re: inserting new records without OIDs |
Date: | 2004-02-19 01:09:10 |
Message-ID: | 40340CB6.5050100@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
> Shhh, didn't think of that. So we won't ever accept unique indices for
> this.
What we do in phpPgAdmin is that rows with NULL values in the unique key
simply aren't editable - all other rows are though.
In order, we prefer to use a PK (since it is indexed), then oid column
(since it is complete), then unique. It's even better if they add a
unique constraint to their oid column :)
>> Also, oids are not guaranteed unique.
>
>
> AFAICS this only happens on wrap around, i.e. hopefully never. Being
> strict, we shouldn't rely on oid uniqueness, but in practice hopefully
> nobody will ever notice.
What phpPgAdmin does for oid edits is it begins a transaction, does the
update, checks to see how many rows were affected. If more than one row
affected, rollback and complain, otherwise commit.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2004-02-20 19:35:30 | Re: BUG: spaces in passwords |
Previous Message | Andreas Pflug | 2004-02-18 22:56:10 | Re: connection dropping continued |