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

On Thu, Jan 23, 2003 at 10:03:28AM -0500, Tom Lane wrote:
> Curt Sampson <cjs(at)cynic(dot)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