From: | Jonathan Bartlett <johnnyb(at)eskimo(dot)com> |
---|---|
To: | Flower Sun <sun_2002_flower(at)yahoo(dot)com> |
Cc: | Pgsql Group <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: About OIDs |
Date: | 2003-03-27 21:14:30 |
Message-ID: | Pine.GSU.4.44.0303271310560.23470-100000@eskimo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
The OID concept is great. Sadly, since they are only 32-bit they can be
problematic. I usually create tables without OIDS and create a field
called object_id of type int8 that uses a global sequence called
'objects'.
The advantage OIDs still have is that OIDs are shown in the data
dictionary.Therefore, with OIDs, you can write a script to merge two
records, and search the data dictionary for any OID-related fields, and
update the related fields with the new OID for the merged record. This
works even if you don't know what tables and columns may be referencing
your table beforehand.
Anyway, that's my take. I'm interested in what other developers have to
say.
Jon
On Thu, 27 Mar 2003, Flower Sun wrote:
>
> Hi, group,
>
> (1) I found system tables are all created without OIDs.
> But the default behavior of creating user tables are with OIDs.
> Is there any benefit to create user tables with OIDs?
>
>
> (2) I heard that OID usage at row level will be a future problems.
>
>
> (3) What's your preference to create table with OIDs or not.
>
> (4) Will drop the whole database release used OIDs?
>
> Thank you
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
From | Date | Subject | |
---|---|---|---|
Next Message | Haroldo Stenger | 2003-03-27 21:15:27 | Re: [HACKERS] Solution to UPDATE...INSERT problem |
Previous Message | Tamir Halperin | 2003-03-27 21:06:39 | Re: Python Error |