From: | Jonathan Bartlett <johnnyb6(at)sdf(dot)lonestar(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: maximum number of rows in table - what about oid limits? |
Date: | 2001-06-08 15:26:57 |
Message-ID: | Pine.LNX.4.21.0106081521080.9063-100000@sdf.lonestar.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
> I've been thinking it should be a compile-time option. But the protocol
> issue is going to be a problem.
The protocol issues shouldn't be a problem if you require separate
drivers. Force clients to use libpq64.so.
The reason I'm concerned about this is that there are a _lot_ of great
things you can do with OIDs if they are unique. For example, if you've
worked with Oracle Applications, they have this tacked on to the end of
all of their tables:
LAST_UPDATED_BY Int,
LAST_UPDATED_DATE Date,
...
Which could be replaced by a single table
Table UPDATE_HISTORY
REFERRED_OBJECT OID,
LAST_UPDATED_BY OID,
LAST_UPDATED_DATE Date
which applies to all tables. You could also have a notes table for
everything -
table NOTES
REFERRED_OBJECT OID,
Note Text
And so on and so forth. However, with OID wrap-around, this would be
problematic.
Jon
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2001-06-08 15:27:05 | Re: very big problem with NULL |
Previous Message | jochen mader | 2001-06-08 15:06:42 | Re: too many clients |
From | Date | Subject | |
---|---|---|---|
Next Message | Luis Sousa | 2001-06-08 15:28:36 | Rule ON DELETE, to perform to DELETE querys ! |
Previous Message | Tom Lane | 2001-06-08 15:04:26 | Re: [HACKERS] Re: behavior of ' = NULL' vs. MySQL vs. Standards |