Re: Call for objections: put back OIDs in CREATE TABLE AS/SELECT

Ross, you make some powerful arguments here.  Probably the most
significant was the idea that you need a unique identifier for every
row, and it should be of a consistent type, which primary key is not.

We clearly need a GUC parameter to turn on/off oids.  But it seems we
will always need the ability to return something like OID to the user if
the user wants it. What it seems we need is a 64-bit oid someday.

As an aside, as Tom already said, the 7.3.X patch is just to make CREATE
TABLE and CREATE TABLE AS behave the same for OIDs.  It does not effect
our defaults for future releases, though this little change in 7.3.0 did
show use that some folks are using OID and did miss them.

---------------------------------------------------------------------------

Ross J. Reedstrom wrote:
> On Thu, Jan 23, 2003 at 10:03:28AM -0500, Tom Lane wrote:
> > Curt Sampson <cjs@cynic.net> writes:
> > > I object. I personally think we should be moving towards not using OIDs
> > > as the default behaviour, inasmuch as we can, for several reasons:
> > 
> > All these objections are global in nature, not specific to CREATE TABLE
> > AS.  The argument that persuaded me to do something here is that CREATE
> > TABLE AS should not be different from CREATE TABLE's default behavior.
> > 
> > I have no problem with moving towards lack-of-OIDs as the default
> > behavior for both statements, in the long run, if we can get past the
> > compatibility issues.  But I don't think OIDs in user tables are costing
> > us anything much, so I'm not prepared to take any big compatibility hit
> > to change the default ...
> 
> Agreed as to taking the compatability hit in the 7.3 branch (you _were_
> talking about changing 7.3, weren't you?) But I think Curt and D'Arcy
> have a point: what OIDs are costing the DBAs and PostgreSQL developing
> community is the pain of having an 'almost' solution in place. OIDs have
> always been the unwanted child in PostgreSQL: the 'pure relational' people
> don't want them, and the Object people are misled into thinking we've got
> a _real_ object id. On the relational side, they've stood in for proper
> use of primary keys (as D'Arcy points out), partly because it's so _easy_
> to misuse them that way: the wire protocol returns the OID for free in
> some cases, and the interface libraries make it easy to get at.
> 
> So the immediate case, changing the default (in 7.3) to match the CREATE
> TABLE case makes sense. However, we need to wean developers off using
> OIDs.  I've been working with Diedrich Vorberg on a thin python object
> relational mapping interface (his Object Relational Membrane - ORM)
> and this was a central problem: you _need_ a unique id for an object,
> and the oid seemed so natural ... 
> 
> So in the longer term, we need to provide a replacement. Arguably, the
> primary key for a table is the right replacement, but we don't _require_
> a pkey, so what to do in cases where this isn't one?  Also, the pkey
> can be _any_ column(s), of _any_ type, which could be inconvenient for
> returning as the result of an insert, for example (imagine a text field
> as pkey, with a _huge_ block of text just written into it ...)
> 
> Ross
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073