Curt Sampson kirjutas N, 23.01.2003 kell 13:34:
> On Tue, 21 Jan 2003, Tom Lane wrote:
> > We've gotten a couple of complaints now about the fact that 7.3 doesn't
> > include an OID column in a table created via CREATE TABLE AS or SELECT
> > INTO. Unless I hear objections, I'm going to revert it to including an
> > OID, and back-patch the fix for 7.3.2 as well.
> I object. I personally think we should be moving towards not using OIDs
> as the default behaviour, inasmuch as we can, for several reasons:
> 1. It's not a relational concept.
so are other system tuples (cid, tid, tableiod, ...).
It is an OO concept.
> 2. The OID wraparound problem can get you.
put an unique index on OID column.
> 3. Other SQL databases don't do this.
Ask Date, hell tell you that SQL is evil, i.e. not relational ;)
> 4. It's hidden, rather than exposed, and hidden things are generally a
> bad idea.
AFAIK carrying hidden weapons is forbidden in most of USA, in Europe you
usually are forbidden to carry hand-weapons _exposed_ ;)
> 5. We should default to what gives us better performance, rather than
Not if it breaks anything ;)
> > See discussion a couple days ago on pgsql-general, starting at
> > http://archives.postgresql.org/pgsql-general/2003-01/msg00669.php
> There didn't seem to be many people clamouring to have it back.
> The ideal sitaution for me would be to have WITHOUT OIDS be the default
> for all table creations, and but of course allow WITH OIDS for backward
> compatability. But yeah, I know that this can introduce problems with
> old dumps, and may not be entirely easy to implement.
If you need a no-OID table, and INSERT INTO it.
Hannu Krosing <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]